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

summary of the Oldenberg d-i debcamp (and release plans)

Between last Thursday and Sunday more than 10 debian-installer
developers participated in the d-i debcamp held during the Oldenburg
developer's meeting. It was quite a successful event, and we appreciated
the hospitality of the Oldenburg developers, and had a good time as well
as doing a lot of work on d-i. But then, if you're subscribed to d-i cvs
and survived the flood of commits, you probably already knew that.

I'll try to summarize everything we accomplished, as well as what
remains to be done. Any innacuracies are my own (please correct them),
and I apologize for leaving out the names of who did what -- too much to
keep track of, and I'm bad with names. The most important part of this
message is probably the last part, which concerns getting ready for the

Perhaps the most significant accomplishment came from the powerpc
contingent, who got d-i fully installing on the powerpc. Motly this
involved fixing yaboot. Some powerpc subarchitectures still lack kernel
images, but this is a major step. Powerpc is perhaps better supported by
debian-installer right now than is i386.

We also have a mips port that is well under way, booting up to the main
menu (with some minor problems). I expect this port is moving too fast
right now for me to properly summarize it.

The alpha port still has boot issues. In particular, we still lack the
source to milo. This is unresolved. Despite this, CD images are in

There was also some s/390 sctivity, but I did not get a summary of

There was plenty of work on i386 as well. We have finally updated to the
2.4.22 kernel for i386 (up from 2.4.20), and the boot floppies have been
fixed to fit the new kernel, as well as having plenty of space to grow
on. There's now a page on the d-i wiki describing i386 netbooting of
debian-installer. The i386 boot disk should soon support usb keyboards,
usb storage devices, and pcmcia as well.

Quite a lot of work was done on general UI issues. The largest change
was increasing the default cdebconf priority to high so we can test how
the installer will actually behave for users. This testing is as yet

Several UI improvements were done in cdebconf, including fixing back
button display, wrapping of text in progress displays, and highlighting
error messages. We still need to comb through the d-i tree for error
messages and make sure they are templates of type "error" and not
"note". Other UI imporovements included making partconf behave sanely
when run a second time.

On the i18n front, main-menu's menu items can now be provided from
debconf templates to allow for easy translation with the rest of the
templates. This transition is still in progress. Along similar lines,
the debconf title can be set to the description of a debconf template
using the new SETTITLE command. This will allow for translated titles,
but there is still lots of code that calls TITLE and needs to be found
and fixed. So now we should have full i18n of everything except some
error messages and, well, the kernel boot messages. Translation work 
continues as usual.

Other work included work on discover2 data reduction (still in
progress), working out how d-i should talk to base-config (still needs
to be implemented), 

We also discussed things that still need to be done. Perhaps the most
important right now is the transition to the new version of
libdebian-installer. Unfortunatly, a lot has changed, and all code that
uses it will have to be updated. There should be a summary posted soon
regarding what has changed in libdebian-installer and how to deal with
it. The rough plan is to get a list of packages that need a fix, assign
them to d-i workers, and try to get the whole tree converted over to the
new version in a 1 week time frame. During this time frame, most other
development on d-i may be blocked.

Here are some other items that need work:

 - Make main-menu set the title of items it runs to the item's
   description (using the new SETTITLE command and the same description
   templates we're now in the process of adding. This will remove the
   need for much manual setting of titles at all, and it will avoid
   confusing titles retained from earlier parts of the installer.
 - Make main-menu not pester the user when a module exits nonzero (but
   detect modules that have crashed with a segfault, and warn then).
 - Try to better organize the language menu. This many involve
   maintaining it manually and picking the placement of new items when
   they are added. Some work on this has occured since I started this
 - Some kind of subarch support is needed by a couple of archutectures,
   so d-i can know the approptiate partitioning tool, boot loader, etc
   to use for the subarchitecture it is being used with. We need a list
   of subarches, and a design. Work on this has started since I began to
   write this summary.
 - Add code to popularity context to track kernel module usage so we can
   better decide which to include where in d-i.
 - Someone needs to start posting periodic status mails again. It's a
   lot of work but it's worth in in improved coordination and awareness
   amoung the larger Debian developer population.
 - We need daily builds for more architectures (possibly reviving the
   idea of a d-i pacage that builds images on the autobuilders), and we
   need the daily builds to be better integrated with the rest of
   debian, and not just off on personal web pages. Ie, in the archive.
 - Someone should probably add some of the above to the TODO or BTS
   so we don't forget them.
 - While we have reasonable docs for d-i developers, nobody at the
   meeting new what the status of the user's documentation is. We need
   documentation for testers now, even if it is not the finished users
   manual. The INSTALLATION-HOWTO is a good, but limited start.
 - We need to make sure that porters who may not be reading this list
   know what ports in d-i need work if d-i is to support them for the
   initial release of sarge.

Finally, and most important, we need a plan for how we will prepare d-i
for the first test cycle. So we tried to come up with one. This was
probably the hardest question of the whole meeting, and this is only a
provisional plan.

0. If Aj decides to stick with his guns and, say, call the beginning of
   the first test cycle on say, Wednesday(!), d-i will provide our current
   best install images, such as they are, for the platforms that have them
   (i386 and powerpc).
1. After the libdebian-installer transition is complete, we will enter a
   feature freeze. No changes should be committed to the tree that have
   the potential to break debian-installer. During this period d-i must
   remain buildable and working at all times. Changes that are unlikely
   to break everything will still be able to be made, with care, but may
   be reverted if they turn out to break anything. If major development
   still needs to be done, developers will need to make branches to work
   in. We should enter this freeze in the next week.
2. Once we're in the feature freeze, it will be (past) time for udebs to
   enter testing, install images to be put in the archive somehow, and so
   on. We will be putting into place everything that must be in place in
   the final release. The daily builds will continue, but once we've
   gotten sufficient reports that a build is a good build, it will be
   propigated to testing, and will become a release candiddate. Release
   candidates will be announced to the user and developer population at
   large, to get even more testing.
3. By the start of the first (or, depending on Aj, second) test cycle,
   we will have a full set of udebs and a d-i release candidate in
   testing, for some set of architectures. d-i will then enter a hard
   freeze, with only important bug fixes and porter changes going in.
   Architectures that are not able to get fully ported in time will then
   have the test cycle(s) to try to catch up.
4. Release.

Finally, I am willing to take over the position of release manager for
d-i, if the d-i group (and Aj) agrees.

see shy jo

Attachment: signature.asc
Description: Digital signature

Reply to: