You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by Leif Hedstrom <zw...@apache.org> on 2012/06/09 00:22:48 UTC
[PROPOSAL] 3.3.x "release" processes
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.
Re: [PROPOSAL] 3.3.x "release" processes
Posted by Leif Hedstrom <zw...@apache.org>.
On 6/8/12 10:06 PM, Leif Hedstrom wrote:
> On 6/8/12 7:30 PM, Bryan Call wrote:
>> I agree with John, I would rather only have and work on trunk and
>> then make a branch two weeks before a release.
>
>
> 1. Two weeks before a dev release, we "git rebase" the 3.3.x branch
> from master.
Forgot to include before, but remember that the 3.3.x branch (if we used
it) would basically be a time delayed version of trunk. So its history
is (eventually) always going to be the same as master, just (sometimes)
behind and perhaps selective. This is why I feel that we don't need to
branch on every development release, a tag should be just fine. If
people really want to create a git branch for every development release,
we can obviously do so, but please explain / justify :).
The various stable branches still need to exist, since their history can
(and will) be considerably different from "master".
Cheers,
-- Leif
Re: [PROPOSAL] 3.3.x "release" processes
Posted by Leif Hedstrom <zw...@apache.org>.
On 6/8/12 7:30 PM, Bryan Call wrote:
> I agree with John, I would rather only have and work on trunk and then make a branch two weeks before a release.
Including feature freezing the trunk (master) for those 2 weeks? My
proposal was what you said, I think, but maybe I misunderstood? In my
proposal, the 3.3.x branch is the branch we work on in that 2 week
period, cherry-picking patches from trunk. In John's proposal, the work
flow is:
1. Two weeks before a dev release, trunk is closed for any and all
feature changes.
2. Bug fixes are allowed on trunk, but nothing else.
3. After 2 weeks, we tag trunk, and cut the release.
In my original proposal, the work flow would have been:
1. Two weeks before a dev release, we "git rebase" the 3.3.x branch from
master.
2. Work continues on trunk as before, mixing both features commits and
bug fixes freely. No restriction applies.
3. Bug fixes goes into the 3.3.x branch (git cherry-pick XYZ1234 onto
the 3.3.x branch).
4. After 2 weeks, we tag the 3.3.x branch, and cut the release.
I think John's proposal is much easier to manage, and this is how e.g.
Mozilla used to work (it probably still does?). When I proposed this
long time ago, there was resistance from feature freezing trunk. If
we're OK with that now, my vote would be to follow John's proposal, and
not worry about branching trunk at all, i.e. after the 2 week period, we
git tag the trunk for the development release, and open up the trunk for
new features again.
Let me know if I misunderstood either of your ideas :).
-- leif
Re: [PROPOSAL] 3.3.x "release" processes
Posted by Bryan Call <bc...@apache.org>.
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.
>>
>>
>>
Re: [PROPOSAL] 3.3.x "release" processes
Posted by John Plevyak <jp...@acm.org>.
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.
>
>
>
Re: [PROPOSAL] 3.3.x "release" processes
Posted by Leif Hedstrom <zw...@apache.org>.
On 6/8/12 5:16 PM, Nick Kew wrote:
>
> 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?
When we first went to Apache, we agreed on 6 months release cycles for
major releases. We can certainly revisit that if we don't want to do
that. The idea was to avoid year long release cycles, and 6 months
seemed reasonable. We have not yet achieved this, in fact, we're on
almost exactly 1 year cycles between major releases. :)
>
>> 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.
Right, that is the 3.3.x branch and cherry-pick from master. I wouldn't
personally branch every time, I'm not sure I see value in that (these
releases are linear). But if we want to create a new branch off trunk
every time (instead of just keeping 3.3.x merged as necessary), I'm not
opposed to that either. (fwiw, git is a much better tool suitable for
dealing with merges, compared to e.g. svn). We would still of course
create release tags for every release, that doesn't change.
As a response to John, I'm not opposed to feature freezing trunk for 2
weeks either. In fact, we had that as a proposal at some point, but some
people objected.
> 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?
>
I think having to add a Jira ticket to say update the STATUS file with
something benign, or some of the other non code related changes is a bit
of a stretch. But, we can certainly make that a requirement too, if
that's the consensus here. I guess what I'm saying is for everyone to
use their best judgement. I do know that there have been a few commits
that most certainly should have had a Jira ticket associated with them,
and they did not.
Cheers,
-- Leif
Re: [PROPOSAL] 3.3.x "release" processes
Posted by Nick Kew <ni...@apache.org>.
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