Re: Complete draft of the March 16th and 30th meetings minutes
Christian Perrier wrote:
> Please comment and correct things if you feel like you have the
> courage to read all that logorrhea.
Ok, I'll sometimes be a bit picky, though it's to have a better
announcement :-)
> 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
technical
> 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].
2009 ...
> This "Bits from the D-I team" post represents the minutes of these two
> meetings and will summary decisions and discussions that happened
summarise
> 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
particulary visible
> difficulties felt to handle the release management work (please refer
> to Nomvember 2008 meetings minutes).
to the November 2008 meeting minutes
It would be good to have a link here.
> 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
s/that/the above mentioned/
> blame on our release manager (Otavio Salvador), except maybe Otavio
> himself. A certain lack of leadership is pointed, with indeed nobody
pointed out
> 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
pointed out
> 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
pointed out
> 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)
Adeodato 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.
>
> 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.
This seems to be mixing two things: the migration script (which is
better known as britney) and the udeb testing summary script. britney
will be extended to support udebs, while the latter script will move
from joeyh's homedir to release.debian.org to have a more up-to-date
(only possible on ries) view as one of the outputs from britney probably.
> 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
summarised (consistent with the other spelling)
> Major goals
> -----------
>
> Persistent device naming
> -----------------------
> That suggestion besomes more and more supported. We want to get rid of
becomes
> 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
summarised
> 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
directions
> 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
Include supplementary?
> --------------------------------------------------
> 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.
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
> 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
This is only one, so maybe the above text should be adjusted to read:
This task has been thrown away because it will almost become void with a
future version of the kernel.
> [1] http://wiki.debian.org/DebianInstaller/Meetings
Ah, I guess that's the link which was not linked :-)
Cheers
Luk
Reply to: