How to cope with patches sanely

Sun Feb 24 21:32:48 UTC 2008

On Sat, 23 Feb 2008 11:20:55 -0500, David Nusinow <dnusinow at speakeasy.net> said: 

> On Sat, Feb 23, 2008 at 09:08:23AM -0600, Manoj Srivastava wrote:
>> Now, you are trying to make me go towards a mechanism I think is
>> inferior (a liner, dependent, and in my opinion, opaque, and somewhat
>> shaky linear patch series) as opposed to pure, independent feature
>> branches, for benefits I still think are dubious, so expect serious
>> push back.  Especially if for every upload I'll have to redo all the
>> integration work of the past; ain't gonna happen.
>> 
>> I am not trying to convince you of the error of your ways.  Please
>> desist trying to convince me of mine.

> No one, not me, nor anyone else in this thread that I've seen, is
> saying that you should abandon your sytem. What we want is a
> consistent method of dealing with differences from
> upstream. Currently, we have one giant .diff.gz, which people hack
> around either with patch systems or vcs's. If we switch to something
> other than a monolithic .diff.gz on top of a .orig.tar.gz, then we win
> because currently we just have a lot of chaos.

        So far, this is OK. The devil, though, lies in the details.

> No matter what you want to say about your feature branches, you *must*
> apply them in a linear fashion to your final source tree that you ship
> in the package. This is no way around it.

        But there is no such linearization, not in the way that quilt et
 al do it.  The state of such integration is not maintained in the
 feature branches; it is in the history of the integration branch.  As
 each feature branch was created or developed, if there were any
 conflicts, these conflicts were resolved in the integration branch. And
 the integration branch does not keep track of what changes come from
 which branch -- that is not its job. And it does not keep the
 integration patches up to date either -- that again is not its
 job. Details below.

        There are only Two use cases I care about. A) Feed each pure
 feature to upstream as an up to date patch against current upstream --
 this is what the feature branch does. B) Have an integrated source of
 all features ready to compile for Debian -- and easy to keep updated
 with lates revisions.  This is the task of the integration branch.

> This idea, a linear stack of changes one on top of the other, is the
> commonality between every one of the different means of handling
> changes to upstream, be they maintained by a patch system or a
> vcs. What we want is to stanardize this concept so that our general
> tools like dpkg are aware of it.

        This is where we start to differ. More on this below.

> Given what I know about your system, the only change you would have to
> make is that instead of integrating directly in a final branch, you
> generate a diff and throw that along with the diff's name in to
> debian/patches.

        I do not think you have thought it through.  Let us try seeing
 how this will not work: Say I have have feature branches A-F.  When
 development happens on branch A that requires some conflict resolution
 on the integration branch, I do the resolution, and fix up the
 integration branch.  The fix applied depends on what order the features
 were merged in -- and this is not something I need to keep track of, so
 I do not.

 As more development happens, and non-overlapping
 changes in the same area occur, the patch would no longer apply.  Other
 feature branches may make changes in the area; and again, make the old
 patch obsolete.

        The a new upstream version comes along, and more changes
 happen.  By this time, the old patch will not apply even to
 upstream. Now rinse and repeat -- the patch you blithely threw into
 ./debian/patches is just dead bit by now.

> That's it. It could be totally automated from your
> current setup without much work, if that's what you want.

        I don't think this can be automated.  However, if you think you
 can solve the problem, I'll stand down my objections.  Love to see it
 demonstrated first.

        Indeed, the only way to redo the information in the integration
 branch is to start with the original upstream, from several years ago,
 determine which feature branch was merged in what order, what order any
 improvements were applied, redo the conflict resolution patches, redo
 the upstream version updates in the correct order, and get to the
 current integration branch.

        Heh. Good luck.

> This is not making you give up anything, it's about improving the base
> standard so everyone can get more information without learning a
> zillion different patch systems and vcs's. As a result, we can focus
> on improving the code itself instead of the process of managing the
> code.

> So, in summary, stop trying to act like you're being forced to do
> something that's going to hurt you. No one is taking away your toys.

        Words. Lets us see some code, eh?

        manoj
-- 
When a man knows no this shore, other shore, or both - such a one, free
from anxiety, liberated, that is what I call a brahmin. 385
Manoj Srivastava <srivasta at debian.org> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C