Adam Majer <[EMAIL PROTECTED]> 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
