Re: output from the vcs-pkg BoF @DebConf9

[Guido Günther]

Hi Stéphane,
On Wed, Aug 05, 2009 at 07:31:13PM +0200, Stéphane Glondu wrote:
 Guido Günther a écrit :
  Looks pretty similar to what I do except that you use upstream while I
  use the debian branch as the base.
 
 This is done on purpose ;-)
thought so ;) this wasn't ment as criticism, i'm just interested in
finding out the reason for the differences to learn from it.

 Actually, my (and Mehdi's) workflow is largely inspired on yours, the
 only thing I changed is basing the patch-queue branch on upstream (and
 not pushing it to the central repository).
 
 I find basing the patch-queue branch on the upstream one more convenient
 because it's much easier to reference the branching point. In this
 regard, basing patch-queue on master doesn't really make sense to me
 and/or leads to too much useless rebasing (at least with the way I work).
You'll have to rebase against the Debian branch if you did changes on it
but that's cheap. Finding the branching point can be done by looking at
the ancestors of the merge commit (if one needs to identify it).

  I do that so I can have different
  patch-queues for different debian releases like:
  
  patch-queue/master
  patch-queue/lenny
  patch-queue/bpo-lenny
  patch-queue/experimental
 
 I don't really see the benefit of keeping patch-queue branches around,
 and I even think they are troublesome. Having each queue serialized in
 its branch's debian/patches is enough, isn't it?
They don't have to be kept around. Whole point is that recreating the
patch-queue branch (for e.g. backports or point releases) works out of
the box. If I understand things correctly in your workflow you'd have to
identify the tag or branch of the old upstream version first and pass
that on to dom-apply-patches? (This could as well be automated of course
by looking at the right tag).

 
  The branch point for the patch-queue branch would then always be the tip
  of the corresponding debian branch, like:
  
  git branch patch-queue/lenny lenny
  git quilt-import debian/patches/series
 
 IMHO, this is really not convenient.
What does the not convenient refer to? 
Cheers,
 -- Guido

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss

Re: output from the vcs-pkg BoF @DebConf9

[Stéphane Glondu]

Guido Günther a écrit :
 [...] Finding the branching point can be done by looking at
 the ancestors of the merge commit (if one needs to identify it).

Sure. But you have to look at your history.

 [...] If I understand things correctly in your workflow you'd have to
 identify the tag or branch of the old upstream version first and pass
 that on to dom-apply-patches? (This could as well be automated of course
 by looking at the right tag).

Right. For branches in the packaging, I create also two branches anyway:
one for debian packaging, and another one for upstream (e.g. sid/master
and sid/upstream), and adapt debian/gbp.conf accordingly in the debian
branch. dom-apply-patches looks at debian/gbp.conf by itself (but
unfortunately, dom-save-patches doesn't work symmetrically... yet, these
scripts are still WIP I guess).

 git branch patch-queue/lenny lenny
 git quilt-import debian/patches/series
 IMHO, this is really not convenient.
 What does the not convenient refer to? 

Basing the patch queue on the debian branch. But maybe it's due to the
way I work: I already do many rebases while working on my local debian
branch and I don't touch upstream sources so much.


Cheers,

-- 
Stéphane


___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss