On Tue, 2009-07-07 at 23:46 +0200, Øyvind Harboe wrote: > On Tue, Jul 7, 2009 at 11:02 PM, David Brownell<[email protected]> wrote: > > On Tuesday 07 July 2009, Ųyvind Harboe wrote: [snip] > Create a release timeout counter which is reset upon > acknowledged regressions reported?
We might not release until X-mas. > > During that week ... should there be a policy on commits, > > with explicit ACKs/NAKs required? Commits can go in after > > the 0.2.0 tarball ships, of course; temporary delays only. > > What about cutting the release and waiting a week > to see if anything of note appears? There needs to be testing of all changes in trunk. That takes a week without significant changes, at our current level of activity. > Upon resetting the release timeout counter, we cut > a new release. The release will be of some well defined > subversion # in the past. > > Cutting a release is *cheap* right? Yes, but there is some cost in having N versions in the field. Sure, we could release after each commit, and we would see few bug reports for any given release. Users have no idea which one is good. This be bad. In contrast, we have been working towards the 0.2.0 release for months. We need a release off which users can perform testing and spot regressions from 0.1.0 (or earlier). Right now, we still require bug reports from SVN, and that will end with 0.2.0 (and sooner is better). Once we fix "enough" bugs we can consider releasing 0.3.0, which will include some additional development. We need to find some balance. Right now, the presses are too heavily biased toward "development" to the extent that "release" suffers badly. Cheers, Zach _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
