Wiki page: http://wiki.debian.org/GitPackagingWorkflow
debian-devel@ thread: http://lists.debian.org/debian-devel/2011/07/msg00771.html

Goals of this BOF:
- Get the global picture of:
  + workflows in use by different groups
  + available tools
- Identify next actions
  + Plan next discussions (on a mailing list)?
  + Write documentation on the Debian wiki?
  + Ask for changes to some tools?
/!\ We should not spend much time comparing the merits of approaches today

Tools/Methods:
==============
Basic tools:
- git-buildpackage (inc. tools like gbp-clone, gbp-pull, ...)
- gitpkg
- git-dpm
- dpkg-mergechangelogs enabled in .gitattributes => That should be somehow more global
- git-stuff (just uploaded the other day, not ready yet for prime-time)

Upstream source:
- in git, pristine-tar to build tarballs
- only tarballs are imported (as opposed to git+tarballs)

Repositories management:
- mr: manage many repositories
- using info from PET to optimize mr performance
- mr-lint: check conformance of repositories
  http://jmtd.net/log/mr-lint/

Management of status inside the repository:
- PET -- http://pet.debian.net/ + http://pet.alioth.debian.org/ (e.g http://pet.43-1.org/pkg-ruby-extras/pet.cgi)
  PET3: http://pet.debian.net/pkg-perl/pet.cgi
- pkg-overview -- http://lists.debian.org/debian-ruby/2011/07/msg00057.html

Patches management:
- git-dpm -- http://git-dpm.alioth.debian.org/ + http://wiki.debian.org/PackagingWithGit/GitDpm
- gbp-pq -- https://honk.sigxcpu.org/piki/development/debian_packages_in_git/
- one branch per patch + manual merging -- http://wiki.debian.org/Teams/DebianMonoGroup/Git (=topgit)
- one branch per patch, thkoch's version -- http://wiki.debian.org/ThomasKoch/GitPackagingWorkflow [madduck doubts it's possible to replace topgit with something less complex but is looking forward to checking it out][just checkout the doc, whether your use cases would be covered - thkoch]
- none, patches² applied +.pc in git
- none, patches applied + --single-debian-patch with dpkg-source (X Strike Force partly uses that)
- none, patches unapplied (no .pc in git)
  - BAD: stores patches in VCS, then have patch of patch to compare
- gitpkg, patches generated at source package creation time (recipes to generate patches using git format-patch)
- do not play with patches. Just one big patch in debian/patches/ (or use 1.0 format)

Changelog management:
* every commit incorporates a changelog entry
  + more linked to Debian source package
  - cherry-picking is a nightmare
* every commit has a verbose commit message but NO changelog entry
  $ git-dch --multimaint-merge --meta --full --since=… --release
  creates the changelog. Then one twiddles bits in the debian/changelog entry to make it better, then commit and tag.
  + cherry-picks are easy
  + git'ty workflow
  - ?

Ian Lane (Mono/CLI) writes:
> What you want:
> 
> 1. Ability to cherry-pick from upstream
> 2. Proper history of patches
> 3. git-blame to work
> 4. Ability to drop patches merged upstream, etc
> 5. Use just the commands provided by git as far as possible (scripts
>    OK as long as they just automate git commands)

Related works:
- UDD (Ubuntu Distributed Development)
- Upload certificates

What are people using? (to complete)
====================================
3 core ideas for patches management:
------------------------------------
A. topgit model / one branch per set of changes
B. patch queue -- one branch that gets rebased to manage patches
C. patches are stored in git, nothing fancy
   dpkg tools will unapply patches (and remove .pc) in the next version

Ruby (lucas):
Basic: git-buildpackage
Upstream source: only tarballs imported
Repo mgt: mr
Status: PET + pkg-overview
Patches: none, patches unapplied
Feedback:
- generally OK, but we need sthing for patches.
- people often forget to git push --all ; git push --tags. is there a shortcut for that?
  solutions:
   update push refs to include tags and pristine-tar
   git-buildpackage has a post-tag-hook that pushes the tag and the branch after a successful build/tag (misses pristine-tar and upstream atm)
   social: teach people how to push and teach them to push their work + tag
   crazy idea: DAK could check, whether there's a tag in the GIT repo of GIT managed
      packages

XXX (XXX):
Basic: 
Upstream source: 
Repo mgt: 
Status: 
Patches: 

Games (evgeni):
Basic: git-buildpackage
Upstream source: mostly pristine-tar, some w/o upstream source at all
Repo mgt: mr
Status: PET + wiki
Patches: usually 'none, patches unapplied'
Feedback: easy, not optimal, patches have to be refreshed by hand,
          easy to give upstream url for patches
Current "flow": http://wiki.debian.org/Games/VCS/git

Forensic (mika):
Basic: git-buildpackage
Upstream source: in upstream branch + pristine-tar
Repo mgt: zsh with vcs_info + git wtf (mika only)
Status: wiki + mailinglist
Patches: depending on maintainer of package
Feedback: easy, patch workflow/handling not optimal, no useful status
          overview (wiki too often out of date, mailing list lacking
          tactical overview)

Libvirt, debian-ha (agx):
Basic: git-buildpackage
Upstream source: pristine-tar
Repo mgt: gbp-create-remote-repo
Status: None
Patches: gbp-pq (optional), patches unapplied
Feedback: Status missing, hooks setup up manually

Debian Printing Team (odyx):
Basic: git-buildpackage (~)
Upstream source: pristine-tar
Repo mgt: usually 'none, patches unapplied'
Status: None
Patches: patches unapplied
Feedback: Works as I'm alone. :-> Help welcome.

Various (madduck):
Basic: topgit
Upstream source: pristine-tar
Repo mgt: none, mr only for vcs-home, not needed for packaging in my case
Status: Suboptimal, but no adequate alternative, four people interested in joining, but it is too complex
Patches: one topgit branch per patch

Various (gio):
Basic: git-buildpackage
Upstream source: pristine-tar
Repo mgt: none (but I should start...)
Status: none
Patches: one branch per patch (with topgit), build branch where where master is
 merged and patch branches are exported as 3.0 (quilt) patches; all branches
 are pushed to alioth (the build branch could be avoided, but it's where
 the debian/* tags are put, so better have it)
Feedback: after having understood a few topgit peculiarities, it mostly
 works well for me; I also sometimes use gbp-pq, but I like it less


pkg-perl (bremner/dam):
Basic: using some git-buildpackage pieces
Upstream source: pristine-tar
Repo mgt: mr+fancy hook helping to avoid 1000s of unneeded pulls
Status: PET + IRC notification
Patches: so far, quilt, unapplied as was done in svn
Feedback: we are just starting

live and everything (dba):
Basic: git-stuff; old docs at (being rewritten and included in git-stuff later):
 http://documentation.debian-projects.org/other/debian-packaging-git-short/
 http://documentation.debian-projects.org/other/debian-packaging-git/
Upstream source: in a branch + pristine-tar
Repo mgt: mr
Status: ml
Patches: none, patches unapplied
Feedback:
- OK, but need sthing for patches (have changes as commits and 'export' to source package with exported patches for quilt).

d-i (dba):
Basic: none
Upstream: only one branch (master; all packages are native)
Repo mgt: mr
Status: ml
Patches: n/a
Feedback:
- imho very messy, all commits include changelog entries (unless someone forgets it), no use of branches, no pristine-tar. rather arcane atm, probably because of the huge impact for people to change from svn to git (that happened not /that/ very long ago (~october)).

pkg-a11y (delYsid):
Basic: git-buildpackage
Upstream source: pristine-tar
Repo mgt: 
Status: (some) irc notification
Patches: quilt, unapplied

Various (pixelpapst):
Basic: git-buildpackage
Upstream source: pristine-tar, master
Repo mgt: stgit
Status: (individual for each contributor)
Patches: quilt (want to replace by stgit or feature branches only)

building from vcs
=================
too much of a change to do in DAK right now, therefore madduck suggests to use a third machine

Signed tags are mandatory to keep the trust chain.
Standardised taxonomy

Upload requests: http://madduck.net/blog/2005.08.11:rcs-uploads/


CategoryGit | CategoryPackaging