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

First (incomplete) draft of the March 16th (and 30th) meetings minutes

Please find below the current status of the March 16th and 30th
meetings minutes.

This is *incomplete*. This is what I had time to cook up today while
coming back from work, so I was cut by...my bus arriving its stop..:-)

Please feel free to amend/correct/etc.

I will of course continue the writing of minutes during the upcoming

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

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 orgaisational 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

 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 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.

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 mainain, 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,
while an option (or a deidcated image) to have D-I images that would
include an SVN snapshot of everything would be interrestin.

[1] http://wiki.debian.org/DebianInstaller/Meetings


Attachment: signature.asc
Description: Digital signature

Reply to: