public inbox for [email protected]  
help / color / mirror / Atom feed
From: Marc G. Fournier <[email protected]>
To: Peter Eisentraut <[email protected]>
Cc: Neil Conway <[email protected]>
Cc: Matthew T. O'Connor <[email protected]>
Cc: Marc G. Fournier <[email protected]>
Cc: Christopher Kings-Lynne <[email protected]>
Cc: PostgreSQL Development <[email protected]>
Subject: Re: Release cycle length
Date: Tue, 18 Nov 2003 00:36:11 -0400 (AST)
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>

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 ...




view thread (83+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Release cycle length
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox