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 release. 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 progress. There was also some s/390 sctivity, but I did not get a summary of progress. 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 incomplete. 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 summary. - 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