Christian PERRIER wrote: > OK, let's throw out a few ideas in the wild. > > Bug triaging could be a good start. Holger did a lot of work recently > with installation reports and confirmed me that he will continue after > DebConf. > > Some progress could be made by looking at bugs already assigned to > soem D-I components. I'd suggest focusing on components that are used > in the standard installation process (localechooser, console-setup, > choose-mirror, partman-base, partman-<useful_filesystems> (and forget > about toy filesystems), partman-crypto, partman-auto, > partman-auto-crypto, base-installer, apt-setup, finish-install, etc.) > > > Localization can get mor ehelp. Some languages are more or less > abandoned with nobody maintaining them anymore. I can provide a list > of these. > > > Nearly all non i386 and amd64 ports of D-I are in very loose > shape. Maybe more attention could be drawn to the non-toy ports > (arm|armel?). > > Processing installation manual bug reports is also interesting and can > lead to better results. This is basically where the boot-floppies were when I started d-i. My origial design goal for d-i was that due to the modularity, individual maintainers or small teams would become maintainers for particular packages relevant to them. This has the benefit that we can use all the regular ways Debian uses to handle keeping important (or not so important) packages maintained by someone. This has not happened a whole lot, but it has happened enough that it still seems feasable. For example, we have the debian-live team handling most of live-installer (and debian-installer-launcher), and the glibc and tools etc maintainers handling providing udebs from their packages. Reasons it has not happened more: * We've built a fair amount of d-i infrastructure, like the l10n, that needs a central management like bubulle. * d-i was in svn and cvs for a long time, and all of it was in a single repo, which encouraged a centralized development model. Now mostly fixed, although most of the udeb packages are still in the d-i alioth group. * d-i has turned out to be not completely trivial for existing package maintainers to learn. They need to learn some special cdebconf stuff, some best practices (?) for monstrous shell scripts, and various other stuff. * It's a PITA to build and test changes to udebs in d-i. But much less than it used to be, with now kvm fast on every laptop except for mine. I still think we could move in the direction of individual d-i packages being maintained by more separate small teams, not all of whom would need to have a full knowledge of other parts of d-i. * busybox could easily be moved out of d-i. Many people would be interested in maintaining it, even if we just orphaned it! Our requirements for it are fairly small (and could be handled by filing bug reports when needed). * debootstrap likewise; many maintainers of other packages have reasons to want it to work, even if they are not interested in maintaining d-i. * bootloader installers could be maintained by the same maintainers of the bootloaders they install. This really makes sense; it's quite hard for general d-i developers to test something like colo-installer, but a bootloader maintainer should have a test rig. * The kfreebsd-kernel udebs could be handled by the kfreebsd kernel maintainers, as has already happened with the linux kernel udebs. * user-setup could be maintained by the shadow/passwd maintainers (not only bubulle..) * Packages like console-setup seem obscure, but produce debs as well as udebs, and are installed on hundreds of thousands to millions of systems. It should be possible to grow a separate team around them. * Similarly, os-prober has a user/developer base that includes not only Debian but other distributions! And many bootloader maintainers should be interested in keeping it working, since their bootloader configurators use it. * flash-kernel is used post-install on many embedded devices; the people interested in embedded debian have an incentive to maintain it. * laptop-detect does not produce udebs at all only debs, and some other debs rdepend on them.. Just the above already drops us from 108 to something like 80 packages. 30 of those are partman, which is its own problem. Forming a partman subteam (or generally, an installer partitioning team), might be a feasable idea. Partman has a learning curve, but once you're over it, it's not very hard to work on, as long as you can keep it in your head and not need to swap it out for other parts of d-i. (Happened to me.) The remaining packages after all the above pruning: debian-installer/ localechooser/ debian-installer-manual/ lowmem/ anna/ lvmcfg/ apt-setup/ main-menu/ auto-install/ mdcfg/ base-installer/ media-retriever/ bterm-unifont/ mklibs/ cdrom-checker/ mountmedia/ cdrom-detect/ net-retriever/ cdrom-retriever/ netboot-assistant/ choose-mirror/ netcfg/ clock-setup/ network-console/ debian-installer-netboot-images/ nobootloader/ debian-installer-utils/ oldsys-preseed/ desktop-chooser/ pkgsel/ dh-di/ preseed/ efi-reader/ rescue/ finish-install/ rootskel/ hw-detect/ rootskel-gtk/ installation-locale/ srm-reader/ installation-report/ tzsetup/ iso-scan/ udpkg/ kickseed/ usb-discover/ libdebian-installer/ win32-loader/ live-installer/ babelbox/ Still a lot, but also most of these are the easier to maintain packages! -- see shy jo
Attachment:
signature.asc
Description: Digital signature