Re: Release cycle length
От | Marc G. Fournier |
---|---|
Тема | Re: Release cycle length |
Дата | |
Msg-id | 20031118002930.U731@ganymede.hub.org обсуждение исходный текст |
Ответ на | Re: Release cycle length (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Release cycle length
(Neil Conway <neilc@samurai.com>)
Re: Release cycle length (Oliver Elphick <olly@lfix.co.uk>) Re: Release cycle length (Sean Chittenden <sean@chittenden.org>) Re: Release cycle length (Bruce Momjian <pgman@candle.pha.pa.us>) Re: Release cycle length (elein <elein@varlena.com>) |
Список | pgsql-hackers |
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 ...
В списке pgsql-hackers по дате отправления: