[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Call for teams interested in collaborating on a 'standard' Git workflow



On Saturday 30 Jul 2011, Lucas Nussbaum wrote:
> On 28/07/11 at 15:36 +0200, Lucas Nussbaum wrote:
> > Hi,
> > 
> > It seems that many different teams have recently switched to Git, or are
> > considering switching. But each of them seems to re-implement the wheel
> > by designing their own Git workflow.
> > 
> > I think that it would be fantastic if we could collaborate on defining
> > a common Git workflow.
> > 
> > [...]
> > 
> > If you are interested in participating (which doesn't mean that you
> > commit on behalf of your team to switch to that workflow, just that you
> > want to participate in the discussions), add yourself (and your team) to
> > http://wiki.debian.org/GitPackagingWorkflow.  If more than 3 teams are
> > interested in a BOF at DC11, I'll try to organize one on saturday (all
> > the video-broadcasted slots are taken, but we will make sure to take
> > notes). If the BOF doesn't happen, I'll contact interested people to see
> > how to continue.
> 
> Hi,
> 
> So a BOF happened at Debconf 11, and I've put the raw notes online at
> http://wiki.debian.org/GitPackagingWorkflow/DebConf11BOF
> 
> My understanding of the situation is that we are ready to document a
> workflow including:
> - using git-buildpackage for basic stuff
> - managing several repositories with mr
> - managing and tracking the status of the repositories (e.g with PET)
> - managing patches with quilt (the "nothing fancy" approach)
>   + additionally, using a patch-queue system (but which one?) to
>     manage patches locally
> - managing debian/changelog with git-dch
> 
> Some people expressed interest in starting a proper documentation on
> that on the Debian wiki. I suggest to use the
> http://wiki.debian.org/GitPackagingWorkflow (or maybe to extend the
> http://wiki.debian.org/PackagingWithGit page).
> 
> We probably need more discussion:
> - on patch queue managers
> - on the "one-branch-per-patch" approaches
Eclipse recently moved to one-branch-per-patch, or at least one branch
per issue being fixed.  This seems to be the fashion.

David
> 
> Also, Raphael Hertzog mentioned that the next version of dpkg will
> unapply patches and remove .pc after the build, which should help with
> managing patches in git.
> 
> - Lucas


Reply to: