On Sunday 08 October 2006 04:19, David Nusinow wrote: > If you have concrete suggestions for how to handle these things in the > future, and even right now, please post them in a reasonable manner. Maybe some insight in how this works in the Debian Installer team may help. Note that every team (and every release manager) is different, but basic ideas should still be applicable. Both projects (D-I and XFS) are somewhat comparable, especially since XOrg has gone modular. One important difference is of course that a lot of D-I is original, Debian-specific code while XOrg is mostly "just" packaging. Tracking changes ---------------- For the D-I repo we have _loads_ of people with commit access, mostly translators but also a fair number of porters and (past) developers. This means that an important tool to keep track for the RM are the CIA commit messages on #debian-boot and the mails that are sent to p.qa.d.o (the PTS) for each SVN commit. We do not have max size limit on the mails, which is possible because they are not sent directly to the d-boot list, but through the PTS. As RM I at least quickly take a look at all commits that are not purely translation updates (which luckily are easily recognizable). The main purpose is to follow what is happening, but a second goal is peer review of changes so we can hopefully catch errors early and to check for consistency between components. How closely I look depends on who made the commit and which component was changed (I tend to look less closely at architecture specific components than general ones). Joey Hess and Colin Watson also check commits in this way, but possibly more selectively. Committing changes ------------------ In principle almost all packages are team maintained and have the d-boot list as Maintainer and one or more developers as Uploaders. In practice a lot of components (or in some cases specific parts of components [1]) have one (maybe two) "main" maintainer(s) who take care of it. In these cases the main maintainer normally has the freedom to upload when he wants. If changes are invasive or when we are close to preparing a release, he will often ping me (as RM) first. A lot of D-I components are fairly mature and "abandoned' to general maintenance. In those cases anybody can commit, but uploading will mostly be left to me as RM [2]. I will check with the committer before uploading if I'm unsure of the status of such pending changes and will often test changes locally before uploading. A few senior team members (joeyh, kamion, tbm) will also uploaded when needed, especially if there are no (or only trivial) pending changes by others. I also track pending uploads of arch specific packages and will mostly ping the relevant porters if an upload is needed for a release (e.g. because of translation updates). I try to encourage sending patches to the BTS or the list for comments before committing if people are unsure of their changes. Releasing --------- In general active team members will know when a release is coming up. However, I try to clearly announce when preparation for a release is actually started and the schedule I hope to follow, and to send updates when needed. I try also to explicitly mention planned freezes and make requests to not upload without contacting me first. We also keep a wiki page for each release: http://wiki.debian.org/DebianInstaller/EtchRC1Prep I have some tools available that help me to track pending (translation) changes and version differences between unstable and testing (important as udebs currently don't migrate automatically). QA and teamwork --------------- As RM you sometimes find yourself in a position where someone is making life for the team as a whole (and the RM in particular) harder than necessary, either by regularly committing low quality or untested patches or by not having enough consideration for the juggling act an RM of a large or complex project has to perform or by in general not behaving as a team member. In those cases IMO the RM _has_ to speak up and may, after consulting with other (senior) team members, eventually be forced to take action. I don't think I need to give an example here. Hope this helps, FJP [1] Good example is cdebconf where the GTK frontend has a separate maintainer from the general code and other frontends. [2] Because of this both Joey (as previous RM) and I are uploaders for most components as this is needed for bug closure and I will add myself when needed.
Attachment:
pgpxuO3TyR6xH.pgp
Description: PGP signature