Robert Haas wrote:
> That having been said, I think there is a legitimate concern about
> organizing and documenting the steps that are required to get a
> release out the door. A number of people have said (on this thread
> and previous ones) that we didn't know what we were supposed to be
> doing during the period after the end of the last CommitFest and prior
> to release. It appeared that all of the activity (to the extent that
> there was any activity) was by committers, particularly you and Tom.
>
> Well, OK. We want the release to happen faster next time. We're
> willing to help. In order to help, we first need a list of the tasks
> that need to be completed after the last CommitFest and before
> release. Then we can try to figure out whether any of those tasks can
> be done (or assisted with) by someone other than you or Tom.
>
> Can you provide one?
Well, at the end of the release I have a mailbox full of open items,
that I think need to be addressed before we go into beta. Tom has a
similar list. I usually put my mbox file up on a web site, and
sometimes it is transfered to a wiki by others.
Knowing about the problem usually isn't hard , e.g. \df, but getting
agreement on them is. One nifty idea would be to do a commit-fest for
open items so we can get to beta. The last commit-fest usually is long
because we can't postpone patches easily and often we are not 100% sure
how to apply them either, so that make it extra-long.
I am not sure what other checklist items there would be (or I am
refusing to divulge).
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
