Messages in this thread |  | | From | devnull@spaans ... | Date | Wed, 13 Sep 2000 14:57:51 -0400 | Subject | Re: Proposal: Linux Kernel Patch Management System |
| |
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/
|  |