Debian kernel: various issues to discuss
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 debian-kernel@lists 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
leader@debian.org
Reply to: