Re: Debian kernel maintainter takeover
On Wed, 12 May 2004 06:40:27 +0200, Goswin von Brederlow wrote:
> Adam Majer <adamm@galacticasoftware.com> writes:
>
>> Christian T. Steigies wrote:
>>
>>>On Tue, May 11, 2004 at 05:15:56PM -0500, Adam Majer wrote:
>>>
>>>
>>>>1. How and who will take over the lead of kernel maintenance?
>>>>
>>>>
>>>
>>>I do hope that Herbert stays the kernel maintainer.
>
> 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.
>>>
>>>
>>>> 2. Where will we have the kernel sources? Will these reside in a CVS?
>>>> Or bitkeeper?
>>>>
>>>>
>>>>
>>>Bitkeeper? How many people would be able to read that? Not that it
>>>matters, since Herbert is going to stay the maintainer, right? Or has
>>>there been a
>>> definite resignment yet?
>>>
>> Just look in debian-devel [1].
>>
>> Anyway, bitkeeper or CVS would just be for kernel developers, and not
>> for the end user. I think it would be advisable to have the kernel
>> repository on a relatively private server that has enough room for it
>> -PCI_DEVICE_ID_TIGON3_5700,
>> for example, gluck.d.o should suffice. Again, this would not be world
>> readable, not central repository for the public but for the kernel
>> maintainers and these already have access to gluck. Any comments?
>
> I don't have access there.
>
> I would suggest using something that can handle multiple branches and
> makes version tracking between branches easy. It would be nice if we
> could add branches for seperate archs that can easily synchronise with
> the main branch.
>
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.
>>
BTW, The end user installs the kernel tree using dpkg (dpkg, apt-get,
>> etc..).
>>
>>>> 3. The current kernel source is quite different from the vanilla
>>>> kernel. Should we try to maintain the extensive set of patches that
>>>> are applied to the Debian kernel (and are not Debian specific)? Or
>>>> should we revert to the vanilla kernel and not backport things from
>>>> 2.6.x kernel to 2.4.x (eg. IPsec)?
>>>>
>>>> IMHO, I would think that the best way to go would be with the vanilla
>>>> kernel or as close as possible to vanilla kernel, but I would like to
>>>> get some other opinions.
>>>>
>>>>
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.
>>>>
>>>I don't know where he gets the patches from, but I think a big part is
>>>the removal of non-free drivers. Not something I would want to dig
>>>through... Those probably still have to be removed, if I interpret the
>>>outcome of the latest vote correctly. Kinda rules out bitkeeper, too I
>>>would think.
>>>
>>>
Yes, removal of non-free bits is something we won't have much of a
choice about.
>>>
>> There most likely will be patches from -preN or -rcN release of the
>> kernel that might be advantageous to have, but there will be other,
>> non-official patches that fix things on archs supported by Debian, but
>> not supported directly be kernel.org. I think that ARM support falls
>> into this category, well, at least for a while.
>
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.
Reply to: