Re: Help with 2.15.1 release.

[Roland McGrath <roland at hack dot frob dot com>]

It certainly was never the intent when we originally established the
release branch and release manager scheme that the release manager would
do the actual backporting work.  In fact, I was explicit at the time
that nobody should be doing things that way at all.  The idea of the
release branch is not just that it gets backports that "make sense".
The idea is that the purpose of releases is to have system-builders use
them in building packaged systems.  Those folks usually apply various
patches to their releases, including backports of trunk bug fixes that
they've deemed worthwhile for the users of their stable system releases
to have.  In the original conception, the release branch was a place for
backport patches that multiple system-builders were already using and
agreed were a good fix.  The release manager's role, then, is to collect
candidate patches from people who are already using and testing them,
verify that they are only backports consistent with the behavior of
changes already on the trunk, judge that they are stable and noninvasive
enough to to be appropriate for the particular release branch, and lead
a consensus decision on when the branch has collected enough fixes that
it's a good time to make a point release.  This involves a lot of scut
work fiddling bugzilla, juggling git stuff, coordinating with other
hackers, making tarballs, sending announcements, etc., but not very much
actual coding at all.

IMHO, anyone who has marked a bug requesting a 2.15 backport and has not
already done the backport, tested the code, exposed their users to it,
and reported all those details, is not holding up their end and you as
release manager should either harangue them or feel free to ignore them.


Thanks,
Roland