On Fri, 08 Jun 2012 16:22:48 -0600
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.
-0. Not a strong objection, but why the need for a 'strong plan'
an a six month cycle?
> 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).
I guess the solution here is to fork a release branch two weeks ahead
of rolling its release. Then only bugfixes are allowed in the branch,
while trunk rolls on as normal.
> 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.
Seems OK, except insofar as it begs the question of whether we want to
push everyone into creating jira issues even where they may seem pointless.
Sounds like you're basically saying jira should be a public record of
every non-trivial commit. I can live with that, but would just like to
confirm whether that's what you mean?
--
Nick Kew
