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

Re: Question for all candidates: Release process

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 

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.


Reply to: