Robert Haas wrote:
> The release process has multiple parts:
>
> 1. Deciding that we need to do a release, either because $BUG is
> really bad or because we have security fixes to release or because
> enough time has gone by.
> 2. Updating translations and time zones and release notes and stamping
> version numbers and building tarballs.
> 3. Packaging and releasing tarballs.
> 4. Writing and publicizing the release announcement.
>
> #3 happens on pgsql-packagers and AFAICT it works fine. The problems
> are primarily with #1, and sometimes with #2 to the extent that Tom
> and Peter pretty much do them every time, so if they're not available,
> nobody else can step in. I have no complaints about #4.
I am familiar with the part of #2 that Peter does, so I could do that in
case of need. Not sure about the tzdata updates, but I expect that it
should be reasonably straightforward. Stamping version numbers and
building tarballs are tasks now scripted, so I think any well-documented
release officer could do them also. Of that bunch, writing the release
notes seems the most difficult.
I think #1 is the part that we seem to have the most trouble with. It
seems easily fixable: establish a new mailing list for that task (say
pgsql-release) and get all the current -core in there, plus the set of
active committers. That group would handle tasks #1 and #2 above.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services