FOlks, here is the complete draft of a report of our important
meetings, which I intend to send as a "Bits from the D-I team" mail in
a few days.
Please comment and correct things if you feel like you have the
courage to read all that logorrhea.
Subject: 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 techn[ical 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 2006 [1].
This "Bits from the D-I team" post represents the minutes of these two
meetings and will summary 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, particularlyvisible in
difficulties felt to handle the release management work (please refer
to Nomvember 2008 meetings minutes).
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 that feeling. Nobody wanted to put any
blame on our release manager (Otavio Salvador), except maybe Otavio
himself. A certain lack of leadership is pointed, 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. 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 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
D-I.
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
sensitive)
- 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 Simo)
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.
Similarly, the installation guide could be uploaded more often, of
course without translation freeze. That would help better spotting
issues, errors or missing parts, hopefully.
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
script/buildscript).
Improve udeb migration
----------------------
The release team is working on a migration script which, among other
tasks, will implement dedicated features for udeb migration. It is not
clear yet whether that script (or the udeb part) would need to run
under the d-i account or not, but that will open perspectives of
lowering the number of boring tasks to do in release preparation.
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 besomes 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 summarized 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 diections 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 Nebur 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
Wishlist
--------
Includes supplemental 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 Nebur 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 fill.
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
satisfactory
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
---------------------
Dropped
-------
These tasks have been thrown away. Some because they have already been
completed and some because no real interest.
- enable relatime/noatime by default
[1] http://wiki.debian.org/DebianInstaller/Meetings
Attachment:
signature.asc
Description: Digital signature