I do observe that the practice of fixed release schedules works well for OpenBSD. Developers have become trained to the schedule and plan their own lives and vacation time around that schedule.
- a On 6/9/07, Christopher Schmidt <[EMAIL PROTECTED]> wrote: > On Sat, Jun 09, 2007 at 09:13:54PM +1000, Cameron Shorter wrote: > > I'm tentatively supportive for a fixed release cycle. > > A fixed schedule will make planning to use Mapbuilder easier. > > > > I'm tentative because: > > 1. There is a reasonable overhead associated with a release cycle, > > (managing issues, testing etc). I'm guessing that Chris is offering to > > provide labour, so in that case this is not an issue. > > I think it's actually less work if we make a harder cut-off for > features. Right now, one of the biggest things that gets decided is > 'when is it done' -- at least for me. This answers that question. Our > actual release process is relatively simple: just follow a couple steps > on a command line, and upload the new tarballs to the server. With > smaller releases, testing is easier because you're breaking fewer > things. etc. etc. > > > > 2. What happens if we go through the release cycle, and find a > > show-stopper bug just before we are due to release? Do we release with > > the bug or hold off. I'd suggest we should hold off. > > Absolutely. No regressions or blockers should be going out in releases, > even if we're behind on schedule. Sometimes things slip. However, with a > hard feature freeze 6 weeks in and a target release date of two weeks > later, that should actually give us time to do testing of things -- > heck, we could even make those testing periods testing binges, where > developers try to write more automated tests. (It's obvious that our > current testing is not complete enough, because *no* testing is complete > enough, but it's actually not that bad.) > > It's good to hear tha tyou're positive on this. > > Regards, > -- > Christopher Schmidt > MetaCarta > _______________________________________________ > Dev mailing list > [email protected] > http://openlayers.org/mailman/listinfo/dev > _______________________________________________ Dev mailing list [email protected] http://openlayers.org/mailman/listinfo/dev
