[cc list is an attempt at stakeholders for this issue. If I missed people, I'm sorry. If I annoyed people by ccing them even though they read the list, well I'm sorry too, but there are a fair number of people who tend to want to be explicitly cc'd when an issue pertains to them.]
Summary: Herbert has started building 8 different flavors of kernel-image for i386. These flavors correspond to CPU type; for example there is an appropriate kernel for people with 386 machines to run and an appropriate kernel for people with Athlon machines to run. Several concerns have been brought up on debian-devel, and while I believe that discussion has identified the tradeoffs involved, I do not believe we have reached consensus on a direction to follow. While Herbert is the maintainer of the kernel image for i386,I believe the implications of this issue extend far beyond his packages and thus this is an issue where the interests of different developers may come into conflict. Herbert's changes affect those who maintain module packages like ALSA, PCMCIA, I2C and Openafs. OSome have claimed these decisions affect the installation by CDs by taking up a significant chunk of a CD. Concerns were raised about the bandwith and archive space implications. I believe that since debian-devel doesn't seem to be able to come to consensus on this issue, we should refer the issue to a smaller group than will fairly consider all the tradeoffs involved and come up with a global direction for the project on this issue. One concern I have with Herbert's decision is that the i386 architecture is taking what appears to be a different direction than other architectures. I'd rather have a global direction than have each architecture go off and do their own thing. Naturally, the tradeoffs may affect different architcetures differently, so we may end up with a different set of kernel images for each architecture, but the relative weights of the tradeoffs and our overall goals could be decided globally. I propose the technical committee as an appropriate form to decide on this issue, but I am open to other fora. I'd like to summarize my understanding of the tradeoffs that we have identified in the debian-devel discussion so that if we do turn this issue over to the committee, they will know what concerns we have already identified. Please add to the following list if I have missed something. Note that I'm not trying to weight the tradeoffs here; I'm trying to be fairly objective. Comments of the form "That's not important," are not appropriate at this time. cThe goal is to identify the issues and let whatever group we send this to evaluate the weights of the issues. Presumably such a group would ask for public comment on the weightings if they would find that comment useful. performance: By having images optimized for each processor on i386 users should see better performance. I don't believe performance numbers were quantified in the discussion but quantifying performance is probably important to evaluating this tradeoff. Encouraging stock kernel use: By having appropriate stock kernels that meet people's needs we may encourage users to use the kernels. This provides better/more consistent testing of our configurationas well as easier upgrade. Herbert indicated that previosly he did not even use his own kernel image packages because they were not optmized. This should be considered separately from performance, because even if there is not a significant performance win, if many more users would use the stock kernel, the advantages of doing so might justify the change. That is, the perception of whether optimized kernels are needed influences whether people use them and the value of this perception may be differently weighted than the actual reality of the performance. Should build custom: Some argumed that users should build a custom kernel and the distribution was doing them a disservice by trying to provide kernels that met their needs. Archive Size: The more kernel images we have, the more space it takes up in the archive. CD Size: Craig (I believe) claimed that the new kernel images take up a significant fraction of a CD. If the number of CDs a typical users actually has to look at gets too big, then Debian will be an inconvenient distribution. It's all fine that have lots of CDs with optional software on them that you don't need, but if you will need a CD of kernels as well as a base CD, (or if the base CD overflows because of kernels), then that could suck. People already complain we need too many floppies to boot; they would probably be more upset if you need more than 1 CD in typical cases. Bandwith: So, moving these kernel images around takes up network resources. Consider resources used to upload the image, resources used to mirror the images resources used to download the images. I don't actually think resources used to download the images changes much, but we should evaluate all network resources. Module Multiplication: Debian has module packages for things not in the kernel or with implementations not in the kernel like PCMCIA and ALSA. Herbert claims that module maintainers will have to build a version of the modules for each kernel image he produces. For most of us that currently multiplies the number of module packages we need to build by 8. For various reasons, most module maintainers seem to want to get kernel sources rather than kernel headers (some of these reasons discussed below, some not directly related to this message). It's somewhat difficult to get kernel sources and appropriate config files in an automated manner especially for non-i386 architectures, so building module packages is labor intensive. Multiplying work by 8 is kind of frustrating. Module size: When you multiply the number of module packages you also moltiply their size. Even if the base size of kernel images is not problematic, when you miltiply in modules size it may be significant. Module Network: Again, you are using more bandwith. Feel free to fold all the module multiplication into one tradeoff if it works better. Kernel headers: Herbert is currently building a kernel headers package for each flavor. There are two problems with this. First, a technical issue in that most of the information in kernel headers is common. This could be solved as a SMOP. The second problem is that other architectures seem to build only one set of kernel headers per version, for the use of glibc. I assue they believe modules will use kernel sources. However, Herbert wants module package maintaires to use kernel headers. We should develop a consistent policy on what we do about kernel-headers for modules. Either kernel-headers are only for libc, in which case we bould one per version, or they are for both libc and modules in which we build one perf flavor.
