[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: status of d-i development -- call for help?

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
* 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
* 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
* 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

Reply to: