How to cope with patches sanely

[Manoj Srivastava]

On Sat, 23 Feb 2008 08:46:03 -0500, David Nusinow <dnusinow at speakeasy.net> said: 

> On Fri, Feb 22, 2008 at 09:37:24AM -0600, Manoj Srivastava wrote:
>> On Thu, 21 Feb 2008 16:20:49 +0100, martin f krafft
>> <madduck at debian.org> said:
>> > That does not help me during an NMU from the source package.
>> 
>> For an NMU of one of my source packages, if you can't deal with the
>> distributed SCM, then you need not worry about differentiating the
>> feature branches, fix the source conflicts, upload. I'll deal with
>> fallout.  Comes with the territory.

> If you're applying 10 to 20 different feature branches to your
> upstream, then that all comes to the NMU'er as one giant diff. This
> obviously sucks and it's what we've been complaining about Ubuntu
> doing to us for years. We can do better.

        I have hear you say this before, but I am not convinced that the
 situations are really similar.  You see, with Ubuntu, I do not see any
 place they provide the information in a nice separate area, even using
 their preferred SCM, bzr.

        That is not the case when using featrure branches, the NMUer can
 get the information they need.

        Now, we should also consider the type of NMU, and the need for
 being able to tell the distinction between different threads of
 development.  As a maintainer, where you are juggling user needs for
 features, and trying to add features, and so on, you do need to deal
 with large changes, perhaps touching a large number of files. Here, it
 do need to tell the lines of development apart, and ensure that all the
 lines of development are indivdually undamaged.

        For this kind of NMU, you need to be familiar with the package,
 and yes, you need to be able to keep features apart.

        Quilt is suboptimal here, since it can't keep features
 independent; since all feaures are impacted by all other features prior
 to it in the linear chain, but I guess it performs well enough.
 Nothing beats a pure featrure ranch in keeping the features
 independent.

        But if you are a security NMUer, you have a short time frame,
 and a very targeted fix to install, and you do not have to keep track
 of independent features, and I believe not having a patched source to
 deal with immediately inder such a use case. The feature branch wins
 again, since dpkg-source -x gives you the sources that are used to
 build from, no special shennanigans needed.

> If you want to use your special custom system then that's fine, but I
> think that ultimately shipping things as a linear patch stack in the
> package makes a lot of sense because you can provide the NMU'er with
> the ability to conceptually see the differences in your branches
> without having to learn your DVCS. That way you can still use whatever
> custom system you want to manage your packages, but at the same time
> you present your packages to others in a way that makes it easier for
> them to work on.

        In this day and age a DSCM is not a mere "custom system".  If
 you want to hack on modern packages, you need to be aware of modern
 tools. Being a Luddite is not something I would encourage.

        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.

> This argument assumes that dpkg-source -x will apply that patch stack
> automatically as well, which has been discussed elsewhere.

        Currently vapourware, no?

        manoj
-- 
You will be singled out for promotion in your work.
Manoj Srivastava <srivasta at debian.org> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C