The fifth Debian Installer team meeting was held from 16:00UTC to 17:00UTC on Saturday September 17th 2005. There were about 72 people connected to the channel during the meeting and 14 of them spoke during the meeting at least once. The full log of the meeting is available at http://people.debian.org/~bubulle/d-i/irc-meeting-20050917/log First etch installer beta release --------------------------------- The main blocker for a beta release has been raised by 2.6.12 kernels reaching testing. Everyone agreed before the meeting that releasing a first beta would probably be worth it only if we are able to get rid of 2.6.8 kernels. A general agreement is reached to get a beta1 out as soon as possible from now. Joey reminds the whole team that a wiki page is setup for beta releases management at http://wiki.debian.net/?DebianInstallerEtchBeta1Prep, which lists all issues considered important for the release. Going through the supported architectures, some do not seem ready for immediate release due to a lack of 2.6.12 kernel udebs, or other 2.6.12-related support such as base-installer support. A concern about hppa is raised during the meeting with BDale's box building the dailies being offline most of the time. A few proposal are made for setting up alternative builds. In the immediate post-meeting discussion, several exchanges came up with BDal and we can expect this issue to be sorted out soon. Martin Zobel-Helas also proposed setting up a machine (which could be a good thing to do anyway, as a kind of backup). About other architectures, the following is decided: -we cannot release without a few architectures considered the "key" arches (because these are the most used for user testing): i386, amd64, powerpc. -other arches are considered mostly working and ready: sparc, s/390, mipsel, arm, m68k probably. Some are hit by a broken binutils. Some building machines use a patched binutils, but a NMU to fix this binutils problem would be needed. powerpc still needs some work on debian-cd, which will probably be done at Oldenburg meeting by Sven Luther. Tasksel needs ftpmaster attention for overrides updates so that, for instance, the laptop task could be available (that one is barely untested up to now). James being over-busy these days, asking Anthony Towns is suggested (or any other developer with the needed rights). There won't be any string freeze for this beta1 release. Translators should catch up with changes as soon as possible. A few languages haven't had any update since the sarge release. Christian will do his best to hurry all translators up. Davide mentions that many variable substitutions errors are found by the spelchecker. This is a good opportunity to remind all translators about the spellchecker: http://d-i.alioth.debian.org/spellcheck/ Davide will try fixing as many of such errors as possible. As a conclusion, the first beta release will go with architectures which are ready at the moment of the release. Other arches will be mentioned in the release notes as "broken". Given that the Oldenburg meeting will help in polishing last things, a beta release could be expected in 2-3 weeks according to the release managers. Regular schedule for D-I meetings --------------------------------- Christian proposes that the D-I team holds regular meetings. Short meetings between 60 and 90 minutes seem the most appropriate. A monthly schedule is agreed by team members. The discussion about the week day to hold meetings does not show a real agreement on a "better" day. Preferences are mixed for both Saturdays and week days. As a consequence, an alternate schedule is accepted, between Saturdays and Wednesdays. The meeting hours are of course difficult to setup. No real consensus emerged except maybe for Wednesdays where using 20:00UTC seems the best (or the less worse). This makes 13:00 to 17:00 for USA, 21:00 to 23:00 for Europe and 05:00 to 08:00 in Japan/Australia/New Zealand. It seem that an earlier hour is preferred for Saturdays. Of course, having a majority of european developers in the meeting probably influences these choices... Christian will propose something more detailed soon. Expect deep discussion.. Status of the graphical installer --------------------------------- Attilio Fiandrotti, after graduating his thesis with a work on the GTK installer, posted a summary of the current status at http://lists.debian.org/debian-boot/2005/09/msg00507.html. The general feeling is that having daily builds of the graphical installer would be a good way to have it tested and usability issues being worked on. In order to not slow down the release process, beta1 will not be released with the graphical installer. Frans proposed setting up a new build target for it so that everyone can easily dig into it and make things work. Attilio reminds everyone that he cannot do this alone, because of missing knowledge of the general build process and Debian packaging. Eugeniy, Davide and maybe Colin seem to be able to work on these issues. However, Colin mentioned that pushing a graphical installer has been put aside in Ubuntu priorities, except for a graphical live-CD-based installer using d-i as a backend. So, the D-I team should not expect much input from there in the short term. Some choices have to be made for the underlying graphical environment: gtk-directfb or X. Eugenyi uses a different X server as a temporary workaround and this solution could be used as an interim way to get something out. User interface certainly needs more work as cdebconf interface does not really fit with Human Interface Guidelines such as http://developer.gnome.org/projects/gup/hig/2.0/ . Several more specialized micro-discussions happned about the needed udebs, the widgets plugins interfaces. See the meetign log for details. As a conclusion, while many things are not really sorted out yet, even when it comes at basic design issues, such as the underlying graphics handling of needed fonts, the focus should be put on getting something usable as soon as possible so that hacking on the graphical installer becomes more widely available. Install reports handling ------------------------ The installation-reports bug log is a big can of worms and we cannot really expect old installation reports to be really useful. The time required for processing them will be too high and required a long knowledge of D-I history. Joey proposes closing all I-R (installation report) using sarge beta3 and earlier releases. Frans adds that this should be done with a message requiring bug submitters to test a more recent version and open a new report if the bug submitter thinks the issue still stands. Frans proposes using the new usertags feature to properly categorize unprocessed I-R. This requires building a list of usertags. Work on closing old I-R and building the usertags list will happen during Oldenburg meeting. There are currently 3 people processing I-R (Christian Mack, Len Sorensen and Frans Pop) while others such as Geert Stappers, Christian Perrier or Joey Hess do some work when they can. Having a semi-official "I-R processing mini team" would maybe help in being sure that we always have someone having a look at them. Promoting stable debian-installer --------------------------------- Geert made a proposal to "patch" the D-I web page : http://lists.debian.org/debian-boot/2005/09/msg00362.html. This patch is aimed to give the sarge branch more visiblity. No-one really opposes this proposal, however Frans suggests this goes in a separate section about the sarge installer, at the bottom of the page. More generally speaking, as all fast moving informations are more and more moving to the Wiki, we might need someone in care of the D-I web pages. Holger Levsen proposes himself for this duty, as he already has commit access to the web site CVS. Frans may act as a backup. Joey mentions that he would like to move the ports status to the Wiki. Conclusion ---------- The next D-I meeting will be held on mid-October, on a Wednesday. The exact hour and day will depend on proposal and discussions following the second topic in this report. A small part of this meeting will have to focus on followups for duties and tasks decided in the current meeting. The energies of D-I team members should now focus on getting beta1 out as soon as possible. Post meeting discussions about better ways to attract more develoment energies show that having new things out is often a good way new people joining the effort.