Re: Debian kernel maintainter takeover
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.
2. Where will we have the kernel sources? Will these reside in a CVS? Or
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 .
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?
BTW, The end user installs the kernel tree using dpkg (dpkg, apt-get,
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
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.
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.
 - http://lists.debian.org/debian-devel/2004/05/msg00719.html
Building your applications one byte at a time