I apologize for the delay in posting something on this topic. When Herbert announced that he was resigning, I talked to him privately to discuss how we can move to a kernel team and which people to involve. I then invited some (upstream) kernel people who use and are interested in Debian to get involved with this effort. Obviously, I was also going to talk to our existing kernel maintainers of other architectures to get them involved in this team. Before I had a chance to do this, William posted the list of upstream people, so it looked as if we didn't consider the existing kernel maintainers at all. This is certainly not the case, as I pointed out to the PowerPC people in private mail already.
I think that this new kernel team is very exciting. I hope that maintainers of all architectures will get involved, and that we can also involve upstream people more than we did in the past. While I'm excited about having a kernel team, I fully admit that I have no idea how exactly this is going to work. It will certainly take some time to get all of us working together. Ideally, we'll get all architectures supported by Debian integrated better into our kernel than we had in the past. However, I'm not sure if it's actually possible to have one source from which all architectures are generated. I think we can also do some experimentation and see how it goes. Below, I'll list some of the issues we will have to consider in the near future. Before that, I'm going to include a "vision statement" from William Irwin about maintaining the Debian kernel: > My specific vision that I'd like to pursue, but am flexible with respect > to retargeting, is to manage a distro kernel in a manner different from > how various commercial distros do now. The specific manner is to track > current mainline exclusively, and to aggressively respond to the issues > encountered and push them to mainline. i.e. instead of forking and > selectively adopting pieces of mainline, producing fixes/etc. based on > our users' demands for mainline. The driving notion is to be as open as > possible and at the same time to reduce unnecessary dead weight like > unmaintainable side trees that have to be periodically abandoned and > reconstituted and desupported and so on and so forth. This requires zero > additional infrastructure to implement. It is done by responding to user > demands (e.g. bugzilla entries) and sending the responses directly to > mainline very aggressively, and likewise with respect to regression tests > for installation, architecture ports, and so on. The essence of this > vision is that the value-add of the distro kernel work is partisanship > for its users with respect to what coding work is done on. This is paid > for by virtue of all users of kernels based on the mainline where the > work was merged or later benefitting from the work, and saves the > complications of version skew and very long-term patch maintenance. > Executing this vision in the context of the debian project has concrete > positive consequences it would not have elsewhere. Specifically, the > debian project supports more architectures than any other distribution, > and so it would enhance the portability of the Linux kernel more so than > elsewhere. The debian project also has an unparallelled upward migration > path in terms of ease and stability, which is something of an ideal > environment for close tracking of current mainline. Some of the issues we'll have to think about are: - what kind of version control system are we going to use, how are uploads coordinated? From the discussion so far, it seems that most people only want to maintain the debian/ tree with all the patches in some version control system, and not actually put the whole kernel in there. Do you prefer to use arch or subversion? If we can agree on one system, I'll ask for an Alioth project to be created. - Some of the kernel people I've invited are not actually Debian developers. I don't think this will be a problem since they use Debian and are well trusted kernel hackers. However, we do have to keep in mind that some of them are rather new to Debian packaging. The nice thing is that we have a good team of people with different skills, so everyone can learn from each other. I've seen many insights from the kernel hackers already, and I'm sure we'll have discussions about packaging issues as well. I have to remind you to be gentle to each other - changing from the current way the kernel was handled to a team will certainly take a while and will require some changes. We can only work together and see how it goes. - Connected to the above two, having a version control system will allow a set of people to commit patches, ideally after they have been reviewed here on this mailing list. William Irwin together with me will decide who will get commit rights to that version control system. - In the past, we had very few documentation and written policies about how the kernel is maintained and which kind of patches are applied (Herbert posted some useful comments to -devel a few months ago, but it was quite unclear before). I think it's important to work out good procedures and document them. - We should try to have similar kernel config files on different architectures (except for arch specific stuff, obviously). We should also discuss whether we should move towards using initrds on more platforms, and where they'd be useful. - Regression test suites: at the moment, kernels on various arches are tested in a very different way. It probably varies from "it compiles, ship it" to really good testing (the HP folks test their Itanium kernels in house with some really good system). The Linux Test project has been mentioned before as well as some other automatic test systems. I think this is really important to have, and I can certainly try getting hardware for this purpose. - Bug tracking. Our Bug Tracking System (http://bugs.debian.org) is used by users to report bugs. The Maintainer: field of the kernel should be changed to [EMAIL PROTECTED] so bug reports are sent here, and then they can be discussed and forwarded upstream. William mentiond that there are scripts to handle bugs, so we'll have to see if we can integrate them with our BTS. - We'll need to figure out how to handle different architectures. Can all of them be built from one tree, or is this not possible. We had discussions about moving to one tree in the past, but then people thought it was too hard and gave up. I think we can only experiment to see if it's possible. - We have to differentiate between the immediate needs and the kernel in the long run. Currently, sarge is sort of frozen and preparing for release (even if the status is not fully clear because of the recent Social Contract change). This means that we cannot make any major changes to the kernel now. Fixes and well tested new upstream kernels are certainly allowed, but changing the way the kernel is packaged or how various architectures are handled cannot be done now. However, this can be worked on, and new packages can be uploaded to experimental for testing. In any case, these are just some of the issues which have to be discussed. I'm really excited about this effort and I hope that everyone is going to work together to make this kernel effort a success. I'm sure we're going to disagree on how to approach things, and we can just try different approaches to see which works best. I hope that in the long run our kernel will improve due to this effort (on all architectures) and that we feed more bug reports and fixes upstream. -- Martin Michlmayr [EMAIL PROTECTED]
