One Git to Package them All, and on the Salsa, Find Them

Talk link:
https://debconf19.debconf.org/talks/68-one-git-to-package-them-all-and-on-the-salsa-find-them/

== Welcome to one git to package them all ==

* Idea is to have a requirements gathering session, to explore the needs for packaging using git in Debian, not to rank or judge those in any way.
* Currently Git / Salsa holds a very different view to the archive, and it would be nice to attempt to consolidate that
* There is bound to be some conflicting requirements
* Unlikely to be able to meet all requirements at wants
* Write down requirements to make sure we don't miss any of them.
* Ian has been making notes about Debian requirements for a while now wrt git-based packaging in Debian
* These kinds of conversations tend to be hard, because we often don't even speak the same language / use the same terminology to describe these things

== Branching Formats ==

* "Unapplied", patches-unapplied, git-buildpackage calls it the "patches unapplied git packaging branch"
  * https://wiki.debian.org/GitPackagingSurvey/unapplied
* Branch formats: what you expect to see when you do git log, branch structure, etc. Often people who are even in the same team will have different ways to work with branches within a repository, teams often have team-specific scripts to deal with this
* Workflow: can vary between users who share branch format.
* Most commons patch manipulation tools are gbp-pq and quilt
* Git packagins survey results: https://wiki.debian.org/GitPackagingSurvey
* We have dozens of ways to use Git to represent Debian source packages, all different

== Open mike! ==

* aigars: for native pacakges, just use git
* ian: there should be a way to mark the point of release to Debian
* holger: "there should not be native packages because we have derivatives" [which break]
 * pollito has noted an objection to this rabbithole
 * ian rephrased this as: it should be easy for derivatives to build on top of our git.
* hartmans: it should be really easy for downstream consumers who use git to modify what we have in git and build it, make it easiers for users to act like a downstream and easily contribute patches
* vagrant: I'd like to be able to `git cherry-pick` upstream commits (not possible in unapplied), but also manage merge requests on Salsa (not possible in git-debrebase)
* hartmans: on the debian group, it's currently really easy for contributors to make a casual nmu-like change to a package, but that's not really possible for other packagers where you're not part of the salsa team
* terceiro: I want the git working tree to look like the unpacked source package
* terceiro (rephrased by hartmans): It's useful to have consistency across a team
* bremner: I'd like people who know git to be able to contribute to Debian without having to know all of our tools. I want to be able to upload without using quilt, debian/patches etc.
* ?1: I'd like to have debian/changelog autogenerated from the git log. Those lead to merge conflicts and makes rebasing more complicated.
 * Ian replies: I don't want to manually generate any changelog stuff)
* noodles: I'd like easy discoverability, how do I find out where the git repo for a given repo lives?  Redirector, directory, something like that.
 * hartmans: add to the above: the ability to get to what the maintainer is currently working on.
* TiN: I'd like to contribute without knowing the workflow of the maintainer.
* hartmans: I'd like to programmatically know which branch format I'm dealing with
* aigars: I want to be able to contribute to debian without even using a command line, I just want to click on edit in a web interface and edit my file
* ian: I'd like translators to be able to contribute without having to deal with patches and/or git, but rather something more suitable for their workflow. (Input from translators needed)
* hartmans: spwhitton couldn't be here today but he had 2 requirements:
  * the archival nature of changes/bug fixes, for example the discussion history on a merge request should be preserved for posterity
  * spwhitton (IRC): discussions are sometimes hard to find within salsa because there are a lot of entry points.  and that could get a lot worse if we had to switch away from gitlab due to factors outside of our control.
  * Ian: wants discoverability of this surrounding discussion, e.g. start with Git history and find the discussion that led to it
* tfheen: git history is a story about how your package has evolved, would like a way to rebase and modify history when it can tell a better story
* (some comment about rebasing, sorry didn't get that - relating to back-porting / cherry-picking commits from upstream and maintaining ordering)
* ian: source packages should go away
* ian: you should be able to "upload" a package by pushing a Git tag\

== Closing ==

If you have ideas or specifics on moving forward, please email leader@debian.org
possibly CCing Sean and Ian if relevant to our tool projects

== Contributors: (add yourself) ==
- bootc
- tfheen
- highvoltage
- petn-randall
- marga
- spwhitton

Other requirements (added after the talk):
* Kurt: Cherry-pick or appply an upstream commit and in the same commit close a Debian bug in the debian/changelog