thanks! and a tiny comment

[Yaroslav Halchenko]

Hi Martin and The List,

Sorry for the delay with my follow up....

On Thu, 11 Oct 2007, martin f krafft wrote:
> > One of the issues we were discussing is an obvious issue of patch
> > maintenance. Feature branches of git seems to be a good straight
> > solution, BUT the possible problem of conflicts among them,
> > necessity to retract them,
> what does that mean?
I just wanted to say that it might be needed to remove the patch from
being applied -- ie remove/pop it from the stack/list of applied
patches. Trivial use case is -- the patch sent to upstream was not
accepted as is, but rather re-worked in some other way (which might even
not conflict with the original patch). So, the patch must not be
applied any longer. If the branch "build"  is a long lasting branch,
where merges from feature branches are committed -- it would be the
place where the patch needs to be "retracted".

> >  * some changes might not be accepted upstream, so they might simply
> >    become deb/... branch later on
> Well, if upstream refuses them, yes, then you cherry-pick them into
> a deb/* branch. If upstream simply doesn't merge them, just leave
> them in upstream-patches. :)
and why to duplicate the effort? imho it is easier to rename
"up/whatever" into "deb/whatever" and preserve the full history of work on
that patch/feature branch if necessary...

> >  * to avoid cherry-picking relevant changes which might be needed
> >  to fix maint/... branch later on (or right now ;-))
> I am not sure what you mean with this.
use case:
 release x.y.z-1 is in etch (for instance)
 while working on x.y.z-12 you came up with a patch to security issue,
 which have to be applied based on x.y.z-1 within a new maint/etch branch.
 If the solution to the problem was devised as a separate feature branch
 (e.g. up/fix_overflow_1), it is simply a matter of cherry-picking or may be
 even merging it into maint/etch branch.

> > So I guess they should precede but be handled the same way as
> > deb/... branches and be named something like up/...
> Sure, you could use multiple upstream patch branches, but that would
> make it more cumbersome for your upstream. Also, I tend to prefer to
> give my upstream one patch per fix, instead of one feature per fix.
probably I have a bit different understanding of feature branches when
talking about upstream-patches (or up/* in my workflow) -- every branch
is either a new feature or simply a fix to a bug ... in both cases the
full history of that branch defines a single patch over the upstream
version

> On the other hand, I think you have to be careful not to succumb to
> branchitis. Feature branches are great, but too many of them are more
> pain than gain. Instead, I think it's better to use only a few, but
> use them orthogonally, meaning that they don't overlap; then you won't
> have any ordering or conflict issues.
100% agree -- fewer is better. Some of deb/* branches might be
even merged at some point if they are definitely not to become a part of
upstream and are not debian release specific.
But 1 branch per fix or a new feature seems to be ok, unless
they have conflicts ... according to the policy iirc, debian
packaging have to be minimalistically intrusive -- ie we should not
create branches from upstream which have various features added on top.
So we should end up only with few deb/* patches and just few up/*
patches.

> You can use a branch locally to work on some Debian-specific
> feature, say related to initramfs integration of mdadm. But when
> you're done and the feature is integrated into the unstable package,
> there is no real reason to keep the feature branch separate from
> deb/initramfs, which hosts all your initramfs-related stuff, and
> thus is unlikely to collide with anything else.
if you were sure that those changes will not have to be applied against
one of already existing by now maintenance releases -- then indeed
feature branch can be merged away ;-)

> > in debian/patches) into build branch, then branch up/bla1  into
> > up/bla1-up and cherry-pick necessary change into up/bla1 after the
> You are talking about policy, but I think that's going a step too
> far. Every package is different and everyone wants to do it
well... I am just trying to expand your guidelines ;-) such approach
would allow easy and consistent handling of conflicts among the patches
(if such occur). If there is a superior way to resolve it -- I would go
for it!

> >  cleanly and we do not hit the same merge issue if we ever need to
> >  unroll and reapply all (or a subset) pf up/.. and deb/...
> >  patches applied within build branch.
> I am failing to wrap my head around all this. I suggest that you go
> ahead and try it out and then report your findings. I had to mess up
> with mdadm *twice* to get to the point where I could write that
> post...
;-) good point... I will give it a try and will report to the list ;-)

-- 
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student  Ph.D. @ CS Dept. NJIT
Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171
        101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW:     http://www.linkedin.com/in/yarik