I like this proposal, but I would rather not have a 3.3.x and just freeze the trunk and only allow commits from patches attached in jira. This would add extra incentive to get the release out and not check in buggy stuff to near that date as all your commits will have to go through jira.
john On Fri, Jun 8, 2012 at 3:22 PM, Leif Hedstrom <zw...@apache.org> wrote: > Hi all, > > after our mini-fiasco with 3.1.4, and the delays of 3.2 in general, I'd > like to propose a few changes to our development release processes. John > made some suggestions here, which I'm formulating in this proposal. > > Please discuss. And yes, we will update the release process on the Wiki > once we agree. > > Cheers, > > -- Leif > > > 1. We formalize a strong development plan for 3.4, and we try to stick > to it. We tried this, very loosely with 3.0 and 3.2, and we failed > miserable. For v3.4, to meet a ~6 month release cycle, we have to > reduce the number of feature additions to something reasonable. > 2. During the development release phase, 2 weeks prior to making a > release candidate, no feature additions are allowed. Period! Bug > fixes are obviously still allowed. (See the 3.3.x branch suggestion > below for how to deal with this). > 3. In order to keep the momentums going, I'm suggesting three additions > to our git processes: > 1. I've created a 3.3.x branch in git. This is the branch that gets > feature frozen 2 weeks prior to someone deciding to start a > release process. Anyone can merge master to this branch as > necessary, up until the 2 week release process starts. From then > on, we cherry-pick from master until the release is cut. > 2. We create feature branches for very large additions. For > example, the DNS rewrite would be a branch, and the NUMA support > would be a branch. Adding support for raw devices in FreeBSD > would almost certainly not be a branch. > 3. Reiterating on our existing process, the master branch on git is > still "commit then review". It is always open, it's always OK to > add features to it. To make things very obvious, lets be > religious about adding Jira tickets to all non-trivial commits, > and annotate the commits (and jira tickets) accordingly. > > >
