Margarita Manterola wrote: > I think that most of the frustration comes from the fact that the > release team is lacking manpower. The job of the release team is very > stressful and very rarely do the RM and RA feel that their work is > appreciated.
I disagree. I think the main problem is that there are two main sides to what the Release Team does and that the cause of the frustration on the side of the rest of the project is that one of those is sides has been neglected. And that frustration in the rest of the project creates the negative feedback and criticism which in turn creates the stress in the RT. The two sides I'm talking about are: - the technical work around preparing a release This includes managing transitions, migrations; doing removals; maintaining tools; etc. This seems to be what the RT has been focussing on after Sarge. This is also where most manpower currently goes. And it's very necessary and important. And in general I think it's done quite well (except when someone decides - without any prior announcement or opportunity for review or comment - to do a mass removal of packages from testing because they have a random RC bug open even though the importance of the package massively outweighs the practical impact of the bug). - the actual *management* of the release process This involves planning and coordinating the work that needs to be done by "regular" DDs; ensuring that not only the archive is in a releasable state, but that also the website and documentation (including translations) have been updated; stimulating BSPs; preparing release announcements (and giving people who's work your announcing time to review and comment what you've written for them); informing everybody involved of the status and progress of a release. And also tracking the status of architectures and *discussing* with the project what to do when an arch has problems (instead of just deciding on things in isolation); keeping track of release goals and stimulating work on them so that they are actually implemented, The quality of a Debian release is determined by much more than just the RC bug count. And it all needs to be managed, or at least coordinated. And *everything* needs to be ready on the day, not just one aspect. During the Sarge release these two sides were in balance. After that, for Sarge stable releases and the Lenny release, the second side was horrible. And several people contributing a lot of work in strongly release-related areas have been driven away by that. After Lenny things have improved in some areas (communication about ports has been quite good for example and so has the management of the last couple of stable point releases), but for Squeeze we've only seen a very few rather general status mails, but no coordination at all. The Release Team should IMO keep in mind that it's not *they* who make a release, but the whole project together. And the best way to get respect for their work is for them to respect the vastly bigger amount of work done by all other DDs collectively. The fact that they control the switches does not mean that they can unilaterally make any decision regarding the work of others. There is no problem with the RT making the *final* decision about release related issues, but they simply cannot make most decisions without checking with the rest of the project. If only simply because in most cases they won't have all relevant information. And checking with the rest of the project is *not* asking a few buddies on a selected channel on IRC. It's doing proper announcement and RFC/RFRs on the mailing lists intended for that purpose. And finally, the best way to get help is to be open about what you're doing. If you hide yourself away and don't communicate with the project you don't get help. I think the very noticeable change in the FTP team is proof of that. IMO for a lot of the above the primary responsability lies with the person with the title/role of Release Manager. Ideally the Release Manager should spend more time on communicating with the rest of the project than on handling transitions. The challenge for an RM when the team can't handle the workload is not to do it all himself, but to continue communicating and get help. Cheers, FJP -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003151630.25818.elen...@planet.nl
