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 days. 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 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 D-I. 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. 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