(also see http://wiki.debian.net/?DebianInstallerMeetings)
The fourth Debian Installer team meeting was held from 14:00UTC to 15:37UTC on Saturday June 18th. This was the first D-I team meeting since we had a pre-release meeting at the end of July 2004, before releasing sarge Debian Installer RC1. There were about 60 people connected to the channel during the meeting and 20 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-20050618/log D-I release management ---------------------- Joey Hess announces his plan to share the "control" of D-I release management. Frans Pop will begin to work along with Joey for the next release of the etch installer and will manage the release of the next version. The goal is to have a first release of d-i ready for the end of July : there are enough post-sarge features ready for wider tests. This needs a revival of the CD builds which should soon happen. The details of the content for this first beta release should be discussed in a specific meeting at the very beginning of July. sarge D-I release management ---------------------------- The whole team agrees that keeping the sarge version of d-i alive is needed but plans are still quite vague about how to achieve this. Colin Watson mentioned his interest in keeping the sarge installer alive and help in managing "point" releases. The amount of needed effort depends however whether the sarge installer is stuck with the 2.6.8 kernel or not. Strict application of the current stable release management rules mandate this, but there's a general feeling among the team that using etch kernels for this would help a lot. The ability to install the Debian *stable* release on recent hardware is a corner stone for the Debian project (and some derived distributions such as Skolelinux). This will require updated drivers and newer kernels in sarge, which in turn may also help solving important issues with *current* hardware such as better SATA support and better cdrom drives detection. All participants agree that these "point" release of the sarge installer must be coordinated with Joey Schulze, the stable release manager. It is also mentioned that efforts will be made to keep the etch installer able to install sarge (just like the sarge installer was kept able to install woody), even if there's still the problem of where it gets the kernels debs from. That issue is actually not completely solved and we may fall short of manpower to really be able to manage these releases, unless new volunteers show up. Several points also depend on discussion with the stable release manager. A dedicated mini-meeting with him might be worth setting up. Christian proposed to organise this. How to get development ramped back up and attract and re-attact more developers ------------------------------------------------------------------------------- The lack of active porters for some arches is quickly raised (this comes quite close from the Vancouver proposal. Let's rephrase : the d-i team feels it cannot maintain d-i for arches if noone from these arches porters works with the d-i team to keep the etch installer alive). Some timely schedule for providing kernel, by the kernel team, could probably help a lot on that issue. Another raised problem is the lack of visible maintenance for some parts of d-i : kbd-chooser, partman are mentioned but there may be others. The main point seems to be that we have problems identifying people "repsponsible" for the packages/udebs. Theoretically, the "Uploaders" field of the package should tell us so, but several are outdated, mentioning people not really currently active. Frans Pop volunteered to realise a summary of all "responsible" persons for d-i packages. This would help tracking down problems when they arise. Some of these should probably be contacted to know whether they intend to continue their work. Another raised problem is the traffic in the debian-boot mailing list. A general consensus raises that directing bug reports and all administrivia messages to a dedicated mailing list would be better. Christian volunteered to request for this list creation and Colin will then do a mass override until packages are re-uploaded with the correct information. A suggestion is made to CC the adresses mentioned in the "Uploaders" field of udeb packages control file to these bug reports. During the discussion, a mailing list for commits is mentioned. [EMAIL PROTECTED] is mentioned to work for this but a dedicated ML would be better. Here again, Christian will handle the list creation. Then all commit mails will be directed over there. The discussion then derived on installation reports (we will keep them in -boot at first), the need to process them (and the changes that could help doing so). Several features are under work such as automated inclusion of logfiles. Coordinating changes -------------------- The initial proposed topic was "how to avoid breaking d-i too badly while doing unstable development; ie, coordinating changes". The discussion starts about automated tests from Joeyh : they currently fail. However, nearly noone but Joey notices this (even iof their results are published at http://people.debian.org/~joeyh/d-i/test-logs.html). The general agreement is to make only one "big change" at a time. Joey gives examples such as : 2.6.11 kernel transition, udev, busybox 1.0, hotplug, 2.6 as default on i386, kbd/console-data transition. Petter adds the move of the timezone setting and root password question to first stage. These changes which are likely to break d-i must now be *announced* and coordinated with the release manager. A list of such big transitions is to be kept alive. Technical evolutions -------------------- keep supporting 2.4 kernel for etch? ------------------------------------ It becomes obvious that maintaining the 2.4 compatibility may become harder and harder. This is however a key point if we want to keep the etch installer able to install sarge. Fully dropping 2.4 support is generally not considered a very good option. After several discussions, the main consensus seems to be on " drop 2.4 support for (sub)arches who already have a working 2.6 support and where 2.4 is no more supported by the kernel team or became useless". However, the need to keep sarge installable mostly sticks us with 2.4 still being supported. This is pretty contradictory and may become a major issue as long as development progresses (post-meeting feeling : this raises an interesting argument to release etch very quickly, actually..:-)). The "Don't delibarately break 2.4" short statement seems a good summary of the discussions. 2.6 installation floppies ------------------------- In short, 2.6 does not fit on floppies. The discussion was not really productive there : Jeff Bailey mentioned some interest and volunteering in getting the 2.6 floppies working even if there's a consensus that the feature is needed. Only one thing is sure : this may be a hard work. 2.6.1* installer ---------------- The issue had mostly been discussed before we came at this point... The concern is whether we need to swith to 2.6.11 (or .12, .13...) right now, with several missing non-free modules such as tg3, or wait until the non-free modules are made available by the kernel team (we barely have the bricks to load them when needed). There seems to be an agreement to go to 2.6.1{1|2|3} as soon as possible even if the price to pay is temporarily lose support for some machines which need the non-free modules. This may be summarized as "we need to move on". Switch back to release names in sources.list -------------------------------------------- The pros and cons are quite well known here but it seems that the 3.1r0a incident has shown that the inability to test release before we release is a major weakness. Several report that themselves use release names instead of "level" names (stable/testing/unstable). An consensus emerges on "Address this by putting release names in if the code name != stable". But, more generally, this is delayed to a later moment. And the consensus in not absolutely complete here. Conclusion ---------- The goal of a release at end July is very ambitious. The work for having it ready on time should start *now*. Another meeting should be scheduled end June/Early July to build a more detailed list of what will and what will not be in the release (etch installer beta1?). A meeting with Joey Schulze is to be scheduled about sarge installer point releases : what will be acceptable and what will not. More coordinated efforts in development are needed, as well as attempts to bring back more manpower to the team. The development of the etch installer has to restart, but backward compatibility with sarge has to be preserved (this was one of the recognized qualities of the sarge installer, to be able to install woody). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
