Re: Debian kernel maintainter takeover
Andres Salomon wrote:
On Wed, 12 May 2004 06:40:27 +0200, Goswin von Brederlow wrote:
Herbert asked me to get signed mails from all willing to group
maintain the kernel on this list and then he would decide. I started
sending out some mails to people I know are intrested but haven't
sends one to all kernel-image/modules/patch maintainers yet.
Anyway, if your intrested in taking over kernel maintainance as a
group here drop me a signed note.
I've got a small list of interested parties (including Goswin) that I've
emailed Herbert. As far as "lead", I don't know if that's how this should
be structured; I'd see more of a release manager type role. Someone
who plans roadmaps for (and prepares) new debian kernel releases. If no
one steps up, I'm fine with doing this.
I would prefer to have DD in charge of making *Debian* kernel decisions.
If a DD is not in the lead, we might just end up removing the Debian
from the Debian-kernel. This is nothing personal and I hope no one takes
it as such.
I would consider bitkeeper out of the question for a central repository.
CVS and SVN are certainly options, although I tend to prefer arch.
Regardless of what's chosen, I plan to still use arch for my own work
(taking what's in the main repository and branching from it). I haven't
been overly impressed with SVN's resource usage; doing a debian-installer
checkout drives the load on my machine nuts for a bit, and is very slow.
Ok. I think it might be a good idea to just stick with CVS then. After
all, it is an old and trusted system used very successfully by other
large projects, like *BSDs.
I would agree with this; a vanilla kernel is desired. However, we're
going to find highly desirable features from newer kernels that users will
request backporting. So, we'll probably end up having a trade-off;
backports of fairly non-invasive things (specific drivers and such) will
probably end up in the kernel. One of the most important tasks of this
group will be vetoing feature requests and third party patches; everyone
is going to want their favorite feature in the official debian kernel. On
one hand, it's nice to not have to keep custom kernels around for features
you want/need (voxel custom kernels, for example, include LVS,
device-mapper, grsecurity, and misc bugfixes). On the other, it's nice
to be able to apply odd 3rd party patches without having a ton of
conflicts due to misc debian-applied patches. Also, we always run into
the threat of introducing debian-kernel-specific bugs with the
introduction of 3rd party patches and backports.
Bugfixes, of course, will be necessary.
Seems fair. If there is a particular driver that is not part of the of
the official upstream release and is in demand, we could add it. Other
changes like device mapper, are too intrusive. This goes especially for
grsecurity (which I use and love :).
I would like to see grsecurity back as a supported patch (that actually
applies) to the official Debian kernel!
I'd consider things like this to be necessary bugfixes. The more we
can get akpm or linus to take, the better.
I wouldn't want to see a radical departure from Hurbert's current kernels
(structure-wise) until after sarge is released. However, once that
happens, I would like to see the build system simplified. This ties in
with the cdbs rewrite that I have plans for, including making it trivial
to generate -source packages with cdbs.
Right now I agree, it is rather late to change things. But we could at
least start the preparations for Sarge+1 kernel.
Coincidently, it appears that over the next week I will end up with a
spare server for development so I could use it to host the Debian kernel
CVS for kernel developers. I would like to see a structure (in the CVS
at least) of
MAIN BRANCH
|
| - Linux 2.4.25
| \-- Debian Linux Kernel Branch
| \-- Debian kernel patches branches
|
| - Linux 2.4.26
| \-- Debian Linux Kernel Branch
| \-- Debian kernel patches branches
|
I believe that this type of structure would eliminate the confusion of
what the Debian kernel changed in the vanilla kernel and also of who
applied what patch for what reason.
Any comments on this?
- Adam
--
Building your applications one byte at a time
http://www.galacticasoftware.com
Reply to: