On Tue, 18 Nov 2003, Peter Eisentraut wrote:
> 0. As you say, make it known to the public. Have people test their
> in-development applications using a beta.
and how do you propose we do that? I think this is the hard part ...
other then the first beta, I post a note out to -announce and -general
that the beta's have been tag'd and bundled for download ... I know Sean
does up a 'devel' port for FreeBSD, but I don't believe any of the RPM/deb
maintainers do anything until the final release ...
> 1. Start platform testing on day 1 of beta. Last minute fixes for AIX
> or UnixWare are really becoming old jokes.
then each beta will have to be "re-certified" for that beta, up until
release ... doable, but I don't think you'll find many that will bother
until we are close to release ...
> 2. Have a complete account of the changes available at the start of beta,
> so people know what to test.
Bruce, when do you do your initial HISTORY file? Something to move to the
start of beta, if not?
> 3. Use a bug-tracking system so that "open items" are known early and by
> everyone.
Waiting to see anyone decide on which one to use ... willing to spend the
time working to get it online ...
> 4. Have a schedule. Not "We're looking at a release early in the later
> part of this year.", but dates for steps such as feature freeze then,
> proposals for open issues fielded then, string freeze then,
> release candiate then.
We try that every release ...
> 5. If need be, have a release management team that manages 0-4.
Core does that, but we just don't feel that being totally rigid is (or has
ever been) a requirement ... but, if you can provide suggestions on points
0 and 3, we're all ears ...
