Re: Debian kernel maintainter takeover
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.
>>
>>
>>> 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
> -
> 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.
> 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 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.
>>
>>
>
> 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.
Debian should have a vanilla kernel source (as far as legaly possible)
and then a set of patches on top of that (like security fixes) that
are independant of the architecture. The arch specific patches are
mostly in seperate packages already which usually build their own
kernel-image-arch.deb and I would like to see that be used for i386
too, even if its just the debian dir in the patch-i386. It would be
more consistent.
So I would like: [but I'm not realy pushing for that, low priority]
kernel-source
kernel-patch-debian
kernel-patch-i386 (also builds kernel-image-i386 debs)
On top of that I would like to extend the dummy packages (kernel-tree)
existing for i386 to all archs: [thats more important to me]
kernel-tree-2.4.26: latest source for Debians 2.4.26 for each arch
Depends kernel-source, kernel-patch-debian, kernel-patch-i386
kernel-tree-2.4: latest source for the latest Debian 2.4.x for that arch
Depends kernel-tree-2.4.26
kernel-image-2.4.26-flavour: latest 2.4.26 image
Depends kernel-image-2.4.26-1-386
kernel-image-2.4-flavour: latest 2.4.x image
Depends kernel-image-2.4.26-flavour
(versions and archs are just examples)
As an extra for people that compile their own kernels I would like to
have kernel-source updates by patches. [an idea for when things have setteled]
kernel-source-patch-2.4.26: patch a 2.4.25 source to 2.4.26
Depends: kernel-source-2.4.25
Provides: kernel-source-2.4.26
Conflicts: kernel-source-2.4.26
The kernel-tree packages should be changed to
Depends: kernel-source-2.4.26 | kernel-source-2.4.25, kernel-source-patch-2.4.26 | kernel-source-2.4.26
I think, not tested yet, that should get apt-get to prefer the patch
if the previous kernel source package was installed. If not
permutating the Depends around should give a combination to that
effect. This might be extensible to more than just the last version
but could get complicated.
The aim is to save people following testing/unstable to allways
download a complete kernel-source with every update.
> As to the non-free binary blobs, these are to be moved to
> non-free. There should be an automatic 'non-free removal patches' (not
> part of the actual debian source). These are then applied to each
> successive upstream kernel release and thus it becomes easier to track
> any firmware changes in the actual kernel. Of course it would be
> better if we could get these 'non-free removal patches' to be accepted
> upstream since these blobs seem to be non-GPL compliant (no source
> code).
>
> But the important thing is that we at least have some sort of a plan
> in motion for transition of the kernel package from Herbert's
> mainteinership. Non-free blobs can wait for a few weeks, until at
> least the GR vote in a week or two.
Herbert has done a very good job in the past and the changes I suppose
above are mostly trivial. We can start off with just taking the
sources as they are and then slowly change things we like to improve
or change.
> - Adam
>
>
> [1] - http://lists.debian.org/debian-devel/2004/05/msg00719.html
MfG
Goswin
Reply to: