thanks! and a tiny comment

[martin f krafft]

also sprach Yaroslav Halchenko <debian at onerussian.com> [2007.10.11.1551 +0100]:
> 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,

sure, you have that with any system that separates the patches: Git,
quilt, dpatch, plain diffs, ed scripts...

> necessity to retract them,

what does that mean?

> As you mentioned, upstream-patches might (and I think should) be actually
> also a set of feature branches (like deb/... are) since 
> 
>  * 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. :)

>  * 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.

> 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.

> In you poor-mans-gitbuild you rely on the sorting of patches to be
> applied as listed by "git for-each-ref" and by default it is
> a refname. ok -- at least it is deterministic. But would not it be
> better to have an explicit control over the order as well as the
> set of patches to be applied? (like debian/patches/00list[.arch]
> within dpatch). Some patches might need to be applied only for
> specific architecture (so we might need master-<arch>/build-<arch>
> branches I guess), or some subset of them to be for a specific
> maintenance branch.

By all means, this is stuff we have to work out. poor-mans-gitbuild
is really just demonstration; I never actually ran it. :)

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.

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.

> I think it might make sense to introduce such a policy: if
> a collision occur during merge of feature branch up/bla1 (listed
> in debian/patches) into build branch, then branch up/bla1  into
> up/bla1-up and cherry-pick necessary change into up/bla1 after the
> conflict get resolved. Upstream should get ...-up branch then

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
differently. So we should provide the generic tools, not the
guidelines, I think.

>  Later on if work is needed on the branch -- work in up/bla1-up and
>  merge those changes into up/bla1, and verify that build merges fine.
>  This way, I think, upstream is guaranteed to get a patch which applies
>  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...

> P.S. As the next step I should make my next attempt to convert my
> SVN's repository for fail2ban packaging over to git to finally close
> reported by you bug(s). Why did I branch and tagged that much? grr....
> ;-)

I have another post forthcoming on this:
  http://scratch.madduck.net/blog__drafts__2007.10.07_converting-a-package-to-git.rst

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net at madduck
 
the heineken uncertainty principle:
  you can never be sure how many
  beers you had last night.
 
spamtraps: madduck.bogus at madduck.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
Url : http://lists.alioth.debian.org/pipermail/vcs-pkg-discuss/attachments/20071011/e8f51b73/attachment.pgp