release manager hat

It seems that Hyrum is pretty happy with having the burden of wearing
a de-facto permanent RM hat lifted off his shoulders.

Even though I played the RM flute for 1.7.4, I would prefer not to
end up in the same de-facto permanent position as an RM.

I think our release process would be more efficient overall if any
developer could, and would, manage a release when the need to make
a new release arises.

What I'd like to do next is clean up the release.py script to the
point where any developer can make a release simply by following the
docs in HACKING and running the release.py script on people.apache.org.
To some degree this is already possible, but the script implements an
old process and needs some updates for a smoother RM experience.

Of course, some amount of pilot intelligence will always remain necessary.
So being RM always takes a little bit of time away from other things.
But I found that there is surprisingly little to do, even with the
current release.py script that has some rough edges.

If we ever issue another 1.6.x release the process will also differ slightly.
Optimising the release.py script for 1.6.x releases is probably not worth
the effort.

What I want to suggest is that I will *not* manage the next release,
and that Hyrum will not manage the next release either. But that someone
else will manage the next release, armed with an improved release.py script
and with on-demand support from myself and, if available, from Hyrum.

Any volunteers?
Received on 2012-03-09 10:22:11 CET