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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
