I agree with John, I would rather only have and work on trunk and then make a branch two weeks before a release.
As for having full patches in Jira, I would think commit messages should be used from trunk inside of Jira. This way we know the fix also went into trunk. -Bryan On Jun 8, 2012, at 3:32 PM, John Plevyak wrote: > 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. >> >> >>
