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?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 adefinite 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?
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.
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.
- Adam [1] - http://lists.debian.org/debian-devel/2004/05/msg00719.html -- Building your applications one byte at a time http://www.galacticasoftware.com