Re: How to cope with patches sanely
On Sat, 16 Feb 2008 20:24:12 +1100, martin f krafft <madduck@debian.org> said:
> also sprach Manoj Srivastava <srivasta@debian.org> [2008.02.05.1751
> +1100]:
>> On Sat, 26 Jan 2008 11:34:27 -0500, David Nusinow
>> <dnusinow@speakeasy.net> said: [...]
>> > An alternate idea I keep seeing is feature branches. I have
>> > absolutely no idea why these are considered preferable to most
>> > people. In the case of the X server we regularly carry around 30
>> > patches on our stack. If we were to put each of these on its own
>> > unique feature branch, merging them becomes an exercise in
>> > pain. Sure, we could implement our own custom scripts and have very
>> > strict naming policies, but then you've re-invented the wheel and
>> > congratulations, you have yet another custom piece of crap software
>> > that you have to maintain on top of the already complicated one you
>> > actually care about. Additionally, you have a lot more branches
>> > getting in the way when you're trying to figure out which one
>> > you're looking for.
>>
>> In my experience, once I have created the integration branch, most
>> upstream versions require little to none re-merging; I just apply the
>> delta to each of the feature branches, _and_ the integration
>> branch. Very rarely do I have to fix up a feature branch, and then
>> apply a second delta with that fix up to the integration branch; but
>> it has not been, for me, painful at all, nor do I have to jump
>> through hoops every single time to accommodate new upstream.
> But sometimes you will have to touch an integration branch and then
> things get messy, especially if there are dependencies between feature
> branches. I think David is making a very strong point here...
No. You never, ever touch an integration branch. If you do,
you are correct in assuming the mouth of hell shall open and
spew forth the demons. The integration branch is only for pulling in
changes from the feature branches; this is why we have a "debian"
feature branch.
You hack in the sloppy branch. You merge change sets from the
sloppy branch into the feature branches. You merge the delta from the
feature branch into the integration branch. In my experience, there is
usually no new mess -- since you are only merging the delta in the
integration branch; the step you took earlier to deal with the mess
usually still apply.
If you are speculating there will be unforeseen and
unmentionable problems, all I can say is that I have yet to experience
them, and not all my packages are trivial packaging of upstream
versions.
> also sprach Ben Finney <bignose+hates-spam@benfinney.id.au>
> [2008.02.07.2242 +1100]:
>> > On Thu, Feb 07, 2008 at 05:12:00AM +0000, Manoj Srivastava wrote:
>> > That's not really about "bring your feature branches" into a patch
>> > system, but rather export them into something that looks like one
>> > so that the security team or the NMUer can have a good outlook of
>> > the modifications you apply to upstream.
>>
>> In the scenario Manoj presents above, the modifications applied to
>> upstream are easily available all in one place: the foo.diff.gz.
> But I may want to see the differences from upstream nicely separated
> into patches, rather than whole chunks?
You mean you do not want to see the differences between a
feature branch and upstream as one chunk, but nicely segregated in
smaller pieces?
> This is the same argument why 32k diffs provided on patches.ubuntu.com
> are useless to Debian maintainers.
Not really, unless your feature branches are poorly chosen.
Each feature branch, in my packages, represent onlogical feature that
belongs in the same patch (series).
manoj
--
Mountain Dew and doughnuts... because breakfast is the most important
meal of the day.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: