How to cope with patches sanely

[Florian Weimer]

* martin f. krafft:

> also sprach Manoj Srivastava <srivasta at debian.org> [2008.02.29.2153 +0100]:
>>   3) I propose ./debian/branches/{TopicA,TopicB,TopicC}.diff.gz
>>      files. Each diff, applied to the orig.tar.gz , shall recreate for
>>      the interested user the corresponding branch in my development.
>> 
>>         Bingo. With this addition, every user that want to see where the
>>  integration branch comes from can examine each topic patch or topic
>>  branch. Each of these topic branches can then be compiled and
>>  experimented with.  Upstream can incorporate each of these topic
>>  patches, if they wish.
>
> ... until I want to play with two branches at the same time, or
> upstream wants to pull two branches. Now you are forcing users to
> deal with potential conflicts.

Yes, but that's way it is.  You can't publish all possible combinations
of branches upstream might need.  If you lump some of them together
(either by combining them altogether, or branching one from the other),
upstream won't be able to take them because there are some changes they
don't want.  If you keep them entirely separate, upstream needs to do
some integreation work.  Either way, there is some work left to do.

> I don't see the added value in your approach. I don't see the use
> case. I know your workflow and note how this is a continuation
> thereof, but I can't identify the benefit to others and the project
> in doing this.

The nice thing about Manoj's proposal that we (as in "the security
team", for instance) need not care if the Debian maintainer thinks that
upstream needs pristine topic branches, an integration branch, a weave,
or whatever.  We just patch the source and be done with it.  This isn't
a problem as long as we tell upstream to pick patches from unstable
(which they will likely do anyway because that version is much closer to
theirs most of the time).