On Tue, Feb 8, 2011 at 4:57 PM, Noah Slater <[email protected]> wrote: > > On 8 Feb 2011, at 09:33, Dirkjan Ochtman wrote: > >> Most of all, I want a better schedule/insight into the release >> process. Even when reading the dev list, it's completely unclear when >> I might expect the next release or what the blockers are. Releases >> seem to just keep slipping, or maybe releasing isn't a very big >> priority, at least that's what it looks like from the outside. > > > The current release cycle goes something like this: > > a. Make a release > > 2. Add features and test them for a while > > d. Schedule a new release following consensus request > > It's a little more complex than that. > > For step 2, we follow the roadmap that is generated in JIRA. That is, the > roadmap is constantly maintained through ticket work and ticket maintenance. > A link to this is even included prominently on the project homepage. We have > found that maintaining a HTML roadmap separately to JIRA is too much trouble. > Or, at least, we could infer that from the fact it was never updated by > anyone. The roadmap (as a JIRA view) is effectively discussed on this list, > and then codified through the tickets. I think that's Good Enough. And if > it's not, then maybe we need to be smarter about how we use JIRA. > > As for step d, this tends to be a consensus based thing. Usually, one of two > things will happen. Either the time since the last release will start to grow > too large, or the amount of features added will. In both instances, > discussion usually starts to bubble up on the list, and this quickly results > in a new release being prepared. The only thing that tends to slow that > process down are release blockers. Like the last release. These tend to be > heavily discussed on the list. I also think that this is Good Enough. > > [1] http://s.apache.org/couchdb-roadmap > >
IMHO a roadmap is defined by more than "there's a new jira issue, we need to fix it with the next release". Till
