Heya, I'm in favour of the proposal. I recognise that there are a few things that need to be refined, but I think what we have is good enough to get going and refine as we go along.
With QA for example, it is up to the release master to judge whether a release is good to go. If the community QA doesn't provide the required results, the release master just won't do a release and thus, we hope, encourage more QA :) Down the road, we might be able to formalise QA more, so we have better strict criteria when a release can go. Ultimately though, this is the release master's call. In addition, I'd like to spend some time on automating some of the tasks so that e.g. feature branches can be run through CI, so we have more transparency into the state of a particular branch during development, but I don't think that is a prerequisite to get this going :) Cheers Jan -- On Jun 16, 2012, at 21:49 , Marco Monteiro wrote: > On 16 June 2012 17:45, Noah Slater <nsla...@tumbolia.org> wrote: > >> 1. We'd like to proposed formal time-based releases > > > >> http://wiki.apache.org/couchdb/Roadmap_Process >> >> > This is a big improvement, but... :) > > If the QA is good enough, it would be a little better to have feature > releases every month or two, support only the latest or two latest > feature releases before a breaking change (but not support anything > older than a year) and have a new release between feature releases for > every bugfix or two. > > Every feature merge would be done on the first one or two weeks, the > remaining time being used to test before the release. > > If QA is good enough, there will be almost no bugfix release. Anyone > wanting to upgrade to fix any issue would always be using the latest > feature release (with any bugfix) for it's major version number. > > This would be much easier to support leaving much more time to make > QA good enough. > > Cheers, > Marco
