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

Bits from the Debian Installer team

After the release of Lenny, for which the Debian Installer team felt
proud for being a part of the technical success....but also guilty for
being one of the release delay factors, the team felt the need to
virtually sit down and discuss about our future, organization and
technical challenges for the Lenny->Squeeze release cycle.

For this, we organized two team meetings that were held on March 16th
2009 and March 31st 2009 [1].

This "Bits from the D-I team" post represents the minutes of these two
meetings and will summarise decisions and discussions that happened
during the meetings.

March 16th meeting: organisational issues

It is no mystery that the D-I team suffered from its low resources
during the Etch->Lenny release cycle, particularly visible in
difficulties felt to handle the release management work (please refer
to November 2008 meeting minutes [2], [3] and [4]).

As a consequence, the first satisfaction was having over 20
participants to the March 16th meeting and a very interactive and
alive discussion.

At the beginning of the meeting, a round table checkup confirmed that
most participants were sharing the above mentioned feeling. Nobody
wanted to put any blame on our release manager (Otavio Salvador),
except maybe Otavio himself. A certain lack of leadership is pointed
out, with indeed nobody really ready to take that leadership. To some
extent, the leadership was shared between Otavio Salvador, Frans Pop
and Christian Perrier, with sometimes obvious lack of real leadership.

That also lead to some core components of D-I to be neglected in some
way, though several team members did a great work maintaining them in
releasable shape.

On the other hand, the lack of developers was *also* pointed
out. Colin Watson noticeably insisted on the demotivation that can
arise when most parts of D-I are frozen because of release
preparation. That seems to have a high potential to demotivate
potential participants to development.

It was also pointed out that former releases of D-I happened under a
strong leadership by very involved, motivated people, who had a very
noticeable amount of time to invest in these tasks (namely Joey Hess,
then Frans Pop, who both lead the work and took the RM work in a
similar way). That model reached its limits, apparently, when the
release manager (who's seen as the leader) has a lower commitment
reliability. As this is more likely than our previous situation, we
need to learn about coping with that.

The general conclusion is that we should try to have a clearer
delineation between ongoing development and release-targeted work.
Both need to happen and both should not conflict.

In that matter, as we were able to release, what seems to be more
missing is the "technical leadership" of the project, while the
release manager remains "the visible person".

A general agreement is that Otavio had to spend too much time on
technical work rather than focus on release priorities
(building/uploading the kernel udebs is given as an example).

Another agreement is that release preparation include a lot of work to
coordinate, some of which could maybe be more automated (such as
building more of D-I on the build daemons, running the daily builds in
a more controlled environment or upload the debian-installer package
more often...).

Finally, after many discussions about various ways to take some load
out of the RM shoulders, we settled on an organization where Otavio
Salvador keeps working as D-I release manager, with some assistance
during the release preparations:
- Christian Perrier for "all boring and tedious non technical tasks" such
  as release announcement, web pages stuff, meeting organization (and 
  reports, doh)
- Luk Claes as dedicated link with the Debian Release Management and
  focusing on technical methods to take as much load as possible for
  the D-I RM
- Jérémy Bobbio and Colin Watson as "Backup experts option" when tricky
  problems that might delay releases are identified

Other widely accepted decisions were:
- try having more technical leadership, not necessarily concentrated on the
  RM shoulders
- do our best to avoid long freezes and keep the development pace active
- try having development corners for our potential new contributors so
  that the team doesn't shrink down to the "core team"

March 30th meeting: technical issues - release goals

After the March 16th meeting that was focused on organisational and
roles issues, we postponed the discussion of technical changes and
Squeeze release goals to a dedicated meeting.

That meeting had slightly fewer attendees, but again lasted for 2
hours and was very alive. Again, that seems to be a sign of the
commitment by several of us that we need to re-improve the pace around

As we didn't go through the entire page of release goals, a new
meeting was decided for April 11th, 20:00UTC.

 General technical organization

Before going to specific release goals, a few general issues related
to technical organization were discussed. Those were a direct
consequence of the conclusions of the former meeting: we should do our
best to make the release management work easier so that it happens
more often and in a more straightforward way.

A more centralized approach for several repetitive tasks has been decided. Tha would cover:
- daily D-I builds for various architectures
- maybe debian-installer package builds (and upload? That's more debated and
- automated l10n stuff (translation syncs, statistics generation and
  -added post-meeting- spellckecher runs)
- maybe udeb testing migration tools (that part very close with the release
  managers, particularly Abeodato Simó)

Luk Claes proposed to get in touch with DSA (Debian System Admins) to
go towards a location where all such stuff would happen under a
central d-i account). Another proposal is using the buildd
infrastructure to build D-I rather than rely on developer's
machines. Access to that common account would be restricted by need
(of course also restricted to DDs as it involves shell access to
Debian machines).

 Release often, upload often

Otavio proposed to work on uploading the debian-installer package much
more often than we're doing right now (more or less only when
preparing a release). That could even be automated to some extent,
though many agree that a manual trigger could avoid nasty accidents.

A proposal was made to upload the installation guide more often, which
Otavio volunteered for. However, post-meeting, Frans Pop indicated
that he's not comfortable with that approach as it doesn't fit the
current work method. As Frans is doing a great job maintaining the
installation guide, his way to organize the work should be preferred
and we drop the initial idea of very frequent uploads of the IG.

By extension, setting up a way to avoid letting improvements and
changes "rot" in SVN is considered worthy. Quite often, because we
have many packages to maintain, we tend to forget uploading them
regularly so that committed changes become available in daily builds.

Going towards fully automated uploads is considered too risky by many
(except for upload with only translation updates), while an option (or
a dedicated image) to have D-I images that would include an SVN
snapshot of everything would be interesting (one of the goals of

 Improve udeb migration
The release team is working on improvements to britney, the testing
migration script which, among other tasks, will implement dedicated
features for udeb migration. 

Simultaneously, the udeb testing summary script that lives in Joey
Hess' home directory [5] should be move to release.debian.org.

 Branching D-I when preparing a release
It has been decided that, in order to not slow down the development
processes, D-I SVN should be branched when the work on preparing a
release starts. Even if SVN doesn't make the process very easy,
changing the VCS we use is currently not an option we prefer.

 Release goals
Goals that were confirmed|added are listed below. These release goals
are summarized on http://wiki.debian.org/DebianInstaller/SqueezeGoals

  Major goals

    Persistent device naming
That suggestion becomes more and more supported. We want to get rid of
devices reordering when rebooting after install, etc. We more or less
decided to make it the top release goal. Colin Watson volunteered to
manage this and already has patches to implement partman/mount_style.

    Find replacement for the ISC DHCP client in d-i
That item is also fairly old. We're using ISC DHCP v3, but it has an
important impact on the size of the initrd. The best option seems to
be using udhcpc from busybox. 

    Switch to console-setup
Using console-setup for keymap and console font selection might solve
a very old weakness of D-I (and overall Debian): different keymap
system for the console and X. The situation is summarised on
http://wiki.debian.org/DebianInstaller/ConsoleSetupSwitch. Samuel
Thibault did already a lot of work on this to solve out the main
blocker: the need to make the keymap names translatable. Colin Watson
and Anton Zinoviev (who was not attending the meeting) could be of
great help in this.

    Ext4 support
Colin Watson did already commit some patches and is aleady following
that issue. Things are essentially waiting on blocking bugs. GRUB
might be a first target.

  Other goals

    General cleanup
This is an old wish. Cruft accumulated here and there in D-I and some
basic work to clean things out might be good and useful. Frans Pop
indeed already did some during Etch->Lenny. Luk Claes would be OK to
help on this but the help and directions from D-I "old timers" such as
Frans or Joey would be great to have.

    Improve support for Intel-based Apple MacBook systems
Current support is a bit of a kludge and needs restructuring. There
are pending patches (gptsync patch to parted) developed for Ubuntu
that Colin Watson could integrate with help of Otavio Salvador.

    Allow selecting disks with GRUB with multiple controllers
Ryan Niebur volunteered for that one. Working with GRUB maintainers
(Robert Millan and Otavio)

    Partman-related goals
Partman is missing someone to take care of it in general and there are a few things that would be "nice to have":
- install partman-ext3 by default: nobody could provide a reason for this
  to not happen so it just needs someone to look at it
- Try to get some issues in libparted fixed: #406680, #328629, #377263
  Otavio told he will look at them


    Include supplementary repository support for udebs
That feature would be useful for derived distros. Bastian Blank has
pending work for this but the dependency resolver is missing on the
new data structures.

    Make os-prober readonly
Bastian Blank agreed to add the patch to support blockdev in busybox
which will help the team to progress on that issue.

    support TFTP to retrieve preseed files
Ryan Niebur volunteered to try working on that one. A TFTP client udeb
is needed for this and, as busybox has one, that could be the way to
go. There are size constraints that might make this goal hard to fulfill.

  Left aside
(nobody really popped up on these ones which were inherited from Lenny)

This is the "newbies, please pick up your task" section.

    Partman-related goals
- Implement "resize partition and install to free space" in guided
  partitioning. There are patches from Ubuntu but not entirely

    Partman-crypto stuff
- partman-crypto: improve entropy handling, add support for
  keys-on-removable-devices, allow devices to be deallocated

- partman-crypto: Allow a user to re-use an existing encrypted filesystem
  without data loss (ex: /home, /srv, etc)

    Kill lvmcfg and mdcfg

This task has been thrown away because it will almost become void with
a future version of the kernel.

- enable relatime/noatime by default 

[1] http://wiki.debian.org/DebianInstaller/Meetings
[2] http://people.debian.org/~bubulle/d-i/irc-meeting-20081107/log
[3] http://people.debian.org/~bubulle/d-i/irc-meeting-20081111/log
[4] http://people.debian.org/~bubulle/d-i/irc-meeting-20081129/log
[5] http://merkel.debian.org/~joeyh/d-i/testing-summary.html

Attachment: signature.asc
Description: Digital signature

Reply to: