Date: Wed, 13 Sep 2000 17:14:57 +0200 (MEST)
From: R.E.Wolff@BitWizard.nl (Rogier Wolff)
Today we fixed a problem in a driver we maintain here. We should've
gone ahead and generate the patch and queued it for Linus. However,
in reality we'd like the complaining customer to test the patch first.
So under a "good" patch maintenance system, I'd have liked to generate
the patch, and have it wait until I approve it.
We talked about doing something like that, but at that point you need
PGP signatures of the developers, and it starts getting very
complicated. Also, I was a bit concerned that if it was too "different"
from what people were used to, they might not adopt it at all. A more
gradual approach might work better. So eventually, yes, it might be
nice to ahve some of the things that you're talking about.
Another features that I REALLY REALLY would like in a patch
maintenance system would be that it could try and automatically
(re-)generate the patch against a different kernel version:
Pushing a patch forward is generally relatively easy to code --- you'll
either get something which will patch correctly, or you won't. You can
even have something automated do a test build. However, that isn't
enough to guarantee that the patch is still valid given other changes
that have since happened.
I personally find that regenering a patch against a newer kernel version
is the trivial part of the exercise. It's retesting and revalidating
the patch afterwards which is a pain, and which takes real human effort
that I don't believe can be automatied.
Isn't this "new" patch maintenance system much like bitkeeper?
Heh. I'm surprised Larry hasn't jumped into this discussion by now.
What we've implemented is a very small subset of the sort of features
that bitkeeper has. The problem with bitkeeper is that it's **so**
different from CVS that it takes time to learn --- I spent a day getting
my head wrapped around it, and I still wouldn't call myself an expert;
that's what's necessary to really get a good feel for how it works and
why it's so nice. The problem, though, is that bitkeeper is only useful
if a large number of other developers use it, and given its non-OSS
license, it's not clear it will get that critical mass. Personally, I
have no problem with the license. But if there are enough other people
who are license fanatics who do have a problem with it, then bitkeeper
loses a lot of value for me. If Linus were willing to dictate from high
that we were going to use bitkeeper, and that all patches had to come in
as bitkeeper changelogs, then that might get us critical mass. If he
doesn't do that, though, my big concern is whether or not it'll be able
to garner enough critical mass for it to be worth the trouble for kernel
developers to want to spend time learning it.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:21 EST