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
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
Reply to: