couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: [PROPOSAL] Official roadmap, and merge procedure
Date Sun, 17 Jun 2012 09:48:00 GMT
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 <nslater@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


Mime
View raw message