Re: How to cope with patches sanely
On Sat, 23 Feb 2008 08:46:03 -0500, David Nusinow <email@example.com> 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
>> <firstname.lastname@example.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
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?
You will be singled out for promotion in your work.
Manoj Srivastava <email@example.com> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C