Minutes of Debian Installer IRC meeting of 20050618
(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.
debian-installer_cvs@packages.qa.debian.org 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).
Reply to: