Branch model discussion

[Jim Apple <jb...@cloudera.com>]

How should Impala branches be a manged?

Today, most of our new development happens on trunk, except when a CDH
release is imminent. I propose we move to a time-based release model,
where development happens on the "master" branch and every N weeks a
commit that is passing all of the tests is tagged with a version
number.

Then we can do an actual release: http://www.apache.org/dev/release.html

For big breaking changes, we could keep two branches around
corresponding to the two versions currently being developed on.

Thoughts?

Re: Branch model discussion

[Tim Armstrong <ta...@cloudera.com>]

Ah, I didn't realise you were thinking about Impala 3.0.

My feeling is that we should try to minimise disruption to the regular
development process on trunk. We could draw a line at some release as the
last 2.x release, and once that's branched from trunk, breaking changes for
3.0 can go in. Depending on how long the window between the last 2.x
release and the 3.0 release, that might mean we have to skip some releases
that have breaking changes, or we could just make them 3.0 "preview"
releases.

On Tue, Jun 7, 2016 at 10:24 AM, Henry Robinson <he...@cloudera.com> wrote:

> On 7 June 2016 at 09:56, Jim Apple <jb...@cloudera.com> wrote:
>
> > Thank you. I think these are good questions.
> >
> > > What would happen if we discover that a tagged release has a critical
> bug
> > > that was missed by the test cases? Would we have a release branch to
> > > stabilise the release with any critical fixes?
> >
> > I think that is the right choice. What do you think?
> >
>
> In other projects I've been involved in, that release would be pulled from
> the distribution pages, and another release (with an incremented version
> number) would be published. Once a version is released, it's pretty
> immutable. Releasing from a branch seems the only sane way to do that.
>
> For a release to happen, someone has to volunteer to be a release manager
> and go through the process of shepherding in all the needed fixes, getting
> the tests passed, dealing with release mechanics (signing, license checks
> etc) and getting the vote passed. Since that's not totally lightweight, I
> don't think we should force the project into a regular every-N-weeks
> cadence without being sure that the release process can keep up.
>
> Instead, if some of the committers want to keep up with that rough cadence
> they should volunteer every N weeks - the distinction I'm trying to draw is
> between a predetermined release cycle, and a best-effort one that makes
> explicit the need to rely on volunteers to drive each release.
>
>
> >
> > > Were you thinking of the scenario where we're trying to stabilise a
> > release
> > > on trunk at the same time as a major feature is in development? I'm
> not a
> > > big fan of long-lived feature branches: I think it's a last resort if
> > > changes can't be staged in trunk in a sensible non-breaking way.
> >
> > For "big breaking changes", you mean? I was thinking of the things
> > that would cause us to move to Impala 3.0, rather than a long-lived
> > feature branch.
> >
> > Do you think Impala 3.0 development should happen on "master"?
> >
>
> I do. At some point before we start taking breaking changes we should cut a
> 2.X sustaining branch so that anyone who wants to make further release off
> the 2.X series can do so.
>
> However, I also think there's a place for individual feature branches, as
> long as they are usually merged back to trunk after the branch meets its
> requirements. A good example is the PPC work - it's a good idea to get that
> stable before it's merged to trunk, but once it's merged, the branch
> shouldn't be needed any more.
>
> Long-lived feature branches are a pain, but we shouldn't rule them out
> entirely if some contributors want to undertake speculative work.
>

Re: Branch model discussion

[Tom White <to...@cloudera.com>]

A few comments inline below.
Tom

On Tue, Jun 14, 2016 at 4:56 PM, Jim Apple <jb...@cloudera.com> wrote:
> Below is some elaboration of what I am proposing. Keep in mind that
> this is not set in stone. It can change at any time the Apache Impala
> (incubating) community wants to change it.
>
> Additionally, not much of this is required by the ASF. The ASF
> requires that a releases happen before graduation in order to verify
> that the community is capable of doing so.
>
> So, the proposal:
>
> Generally, active development should happen on "master". There are two
> exceptions:
>
> 1. From time to time, the community will cut a release. The
> responsibility to release is not a responsibility of any one person,
> but of the community as a whole. However, the responsibility for a
> particular release will be held by one person (or a group of
> volunteers) per release.

The release manager needs to be a committer, so they can tag the
repository, upload artifacts, etc.

>
> There is no set schedule for releases.
>
> If a community member wants to cut a release and the PMC votes against
> it, no release will be created.

Note that release votes are by majority, so no one person can veto a
release by voting -1
(http://www.apache.org/dev/release.html#approving-a-release). Having
said that, it's very common (and polite) to address the concerns of
the person voting -1 and roll a new release candidate.

> Potential release managers should
> discuss release plans with the community and then hold a vote before
> starting the release work.

It's not necessary to hold a vote to decide who gets to release. Any
committer can cut a release and call for a vote at any time. It's not
generally a problem that we have too many releases in an ASF project -
quite the reverse in fact. What usually happens is that someone
suggests that it would be a good time for a release, there's general
agreement, then someone volunteers as the release manager. (This is
all without voting.)

>
> Releases must follow the ASF guidelines:
> http://www.apache.org/dev/release.html#owned-controlled-hardware
>
> Releases must also pass all tests in the repository.

This is not a hard requirement from an ASF standpoint, although it's
obviously highly desirable. The important thing from a legal point of
view is that the release contains only source code, and is licensed
correctly:

http://www.apache.org/dev/release.html#what-must-every-release-contain

>
> The PMC has the responsibility for checking the releases:
> http://www.apache.org/dev/release.html#approving-a-release
>
> Each release will get its own branch. This branch will hold a snapshot
> of the code as of a certain date as well as any cherry-picked patches
> from other branches (presumably mainly "master") as the release
> manager thinks appropriate.
>
> Generally, after release, branches will not receive a lot of
> attention. This means they are unlikely to receive backported fixes
> from "master". Users who want to include those fixes can wait until
> the next release or build their own custom version. This policy can be
> modified on a branch-by-branch basis by lazy consensus.
>
> It is a responsibility of the community to cut a release before making
> big breaking changes to "master" that would constitute a "major"
> release.
>
> 2. Feature branches may be created for speculative work that will take
> a a sequence of changes to be fully realized. These feature branches
> should be approved before being opened by lazy consensus:
>
> https://community.apache.org/committers/lazyConsensus.html
>
> The goal of the committers on any feature branch should be to
> eventually get that branch merged back into "master". Feature branches
> can be merged back into "master" by a vote of the PMC. Feature
> branches that have lost all of their momentum can be closed by a vote
> of the PMC.
>
> +++++++++++++++++++++
>
> Thoughts?
>
> On Thu, Jun 9, 2016 at 10:52 AM, Jim Apple <jb...@cloudera.com> wrote:
>>> I
>>> don't think we should force the project into a regular every-N-weeks
>>> cadence without being sure that the release process can keep up.
>>
>> That sounds good to me. It is my understanding that the way Kudu does
>> it is that someone generally volunteers to drive the next K releases,
>> anticipating creating the release branch every N weeks.
>>
>>> I do. At some point before we start taking breaking changes we should cut a
>>> 2.X sustaining branch so that anyone who wants to make further release off
>>> the 2.X series can do so.
>>
>> SGTM
>>
>>> However, I also think there's a place for individual feature branches, as
>>> long as they are usually merged back to trunk after the branch meets its
>>> requirements. A good example is the PPC work - it's a good idea to get that
>>> stable before it's merged to trunk, but once it's merged, the branch
>>> shouldn't be needed any more.
>>>
>>> Long-lived feature branches are a pain, but we shouldn't rule them out
>>> entirely if some contributors want to undertake speculative work.
>>
>> SGTM.
>>
>> Does anyone else have concerns about this branching model?

Re: Branch model discussion

[Jim Apple <jb...@cloudera.com>]

Below is some elaboration of what I am proposing. Keep in mind that
this is not set in stone. It can change at any time the Apache Impala
(incubating) community wants to change it.

Additionally, not much of this is required by the ASF. The ASF
requires that a releases happen before graduation in order to verify
that the community is capable of doing so.

So, the proposal:

Generally, active development should happen on "master". There are two
exceptions:

1. From time to time, the community will cut a release. The
responsibility to release is not a responsibility of any one person,
but of the community as a whole. However, the responsibility for a
particular release will be held by one person (or a group of
volunteers) per release.

There is no set schedule for releases.

If a community member wants to cut a release and the PMC votes against
it, no release will be created. Potential release managers should
discuss release plans with the community and then hold a vote before
starting the release work.

Releases must follow the ASF guidelines:
http://www.apache.org/dev/release.html#owned-controlled-hardware

Releases must also pass all tests in the repository.

The PMC has the responsibility for checking the releases:
http://www.apache.org/dev/release.html#approving-a-release

Each release will get its own branch. This branch will hold a snapshot
of the code as of a certain date as well as any cherry-picked patches
from other branches (presumably mainly "master") as the release
manager thinks appropriate.

Generally, after release, branches will not receive a lot of
attention. This means they are unlikely to receive backported fixes
from "master". Users who want to include those fixes can wait until
the next release or build their own custom version. This policy can be
modified on a branch-by-branch basis by lazy consensus.

It is a responsibility of the community to cut a release before making
big breaking changes to "master" that would constitute a "major"
release.

2. Feature branches may be created for speculative work that will take
a a sequence of changes to be fully realized. These feature branches
should be approved before being opened by lazy consensus:

https://community.apache.org/committers/lazyConsensus.html

The goal of the committers on any feature branch should be to
eventually get that branch merged back into "master". Feature branches
can be merged back into "master" by a vote of the PMC. Feature
branches that have lost all of their momentum can be closed by a vote
of the PMC.

+++++++++++++++++++++

Thoughts?

On Thu, Jun 9, 2016 at 10:52 AM, Jim Apple <jb...@cloudera.com> wrote:
>> I
>> don't think we should force the project into a regular every-N-weeks
>> cadence without being sure that the release process can keep up.
>
> That sounds good to me. It is my understanding that the way Kudu does
> it is that someone generally volunteers to drive the next K releases,
> anticipating creating the release branch every N weeks.
>
>> I do. At some point before we start taking breaking changes we should cut a
>> 2.X sustaining branch so that anyone who wants to make further release off
>> the 2.X series can do so.
>
> SGTM
>
>> However, I also think there's a place for individual feature branches, as
>> long as they are usually merged back to trunk after the branch meets its
>> requirements. A good example is the PPC work - it's a good idea to get that
>> stable before it's merged to trunk, but once it's merged, the branch
>> shouldn't be needed any more.
>>
>> Long-lived feature branches are a pain, but we shouldn't rule them out
>> entirely if some contributors want to undertake speculative work.
>
> SGTM.
>
> Does anyone else have concerns about this branching model?

Re: Branch model discussion

[Jim Apple <jb...@cloudera.com>]

> I
> don't think we should force the project into a regular every-N-weeks
> cadence without being sure that the release process can keep up.

That sounds good to me. It is my understanding that the way Kudu does
it is that someone generally volunteers to drive the next K releases,
anticipating creating the release branch every N weeks.

> I do. At some point before we start taking breaking changes we should cut a
> 2.X sustaining branch so that anyone who wants to make further release off
> the 2.X series can do so.

SGTM

> However, I also think there's a place for individual feature branches, as
> long as they are usually merged back to trunk after the branch meets its
> requirements. A good example is the PPC work - it's a good idea to get that
> stable before it's merged to trunk, but once it's merged, the branch
> shouldn't be needed any more.
>
> Long-lived feature branches are a pain, but we shouldn't rule them out
> entirely if some contributors want to undertake speculative work.

SGTM.

Does anyone else have concerns about this branching model?

Re: Branch model discussion

[Henry Robinson <he...@cloudera.com>]

On 7 June 2016 at 09:56, Jim Apple <jb...@cloudera.com> wrote:

> Thank you. I think these are good questions.
>
> > What would happen if we discover that a tagged release has a critical bug
> > that was missed by the test cases? Would we have a release branch to
> > stabilise the release with any critical fixes?
>
> I think that is the right choice. What do you think?
>

In other projects I've been involved in, that release would be pulled from
the distribution pages, and another release (with an incremented version
number) would be published. Once a version is released, it's pretty
immutable. Releasing from a branch seems the only sane way to do that.

For a release to happen, someone has to volunteer to be a release manager
and go through the process of shepherding in all the needed fixes, getting
the tests passed, dealing with release mechanics (signing, license checks
etc) and getting the vote passed. Since that's not totally lightweight, I
don't think we should force the project into a regular every-N-weeks
cadence without being sure that the release process can keep up.

Instead, if some of the committers want to keep up with that rough cadence
they should volunteer every N weeks - the distinction I'm trying to draw is
between a predetermined release cycle, and a best-effort one that makes
explicit the need to rely on volunteers to drive each release.


>
> > Were you thinking of the scenario where we're trying to stabilise a
> release
> > on trunk at the same time as a major feature is in development? I'm not a
> > big fan of long-lived feature branches: I think it's a last resort if
> > changes can't be staged in trunk in a sensible non-breaking way.
>
> For "big breaking changes", you mean? I was thinking of the things
> that would cause us to move to Impala 3.0, rather than a long-lived
> feature branch.
>
> Do you think Impala 3.0 development should happen on "master"?
>

I do. At some point before we start taking breaking changes we should cut a
2.X sustaining branch so that anyone who wants to make further release off
the 2.X series can do so.

However, I also think there's a place for individual feature branches, as
long as they are usually merged back to trunk after the branch meets its
requirements. A good example is the PPC work - it's a good idea to get that
stable before it's merged to trunk, but once it's merged, the branch
shouldn't be needed any more.

Long-lived feature branches are a pain, but we shouldn't rule them out
entirely if some contributors want to undertake speculative work.

Re: Branch model discussion

[Jim Apple <jb...@cloudera.com>]

Thank you. I think these are good questions.

> What would happen if we discover that a tagged release has a critical bug
> that was missed by the test cases? Would we have a release branch to
> stabilise the release with any critical fixes?

I think that is the right choice. What do you think?

> Were you thinking of the scenario where we're trying to stabilise a release
> on trunk at the same time as a major feature is in development? I'm not a
> big fan of long-lived feature branches: I think it's a last resort if
> changes can't be staged in trunk in a sensible non-breaking way.

For "big breaking changes", you mean? I was thinking of the things
that would cause us to move to Impala 3.0, rather than a long-lived
feature branch.

Do you think Impala 3.0 development should happen on "master"?

Re: Branch model discussion

[Tim Armstrong <ta...@cloudera.com>]

What would happen if we discover that a tagged release has a critical bug
that was missed by the test cases? Would we have a release branch to
stabilise the release with any critical fixes?

Initially we probably don't need to do this, but I just want to make sure
that we pick a release model that will also work if we need to put more
effort into stabilising releases.

Were you thinking of the scenario where we're trying to stabilise a release
on trunk at the same time as a major feature is in development? I'm not a
big fan of long-lived feature branches: I think it's a last resort if
changes can't be staged in trunk in a sensible non-breaking way.

On Tue, Jun 7, 2016 at 8:59 AM, Jim Apple <jb...@cloudera.com> wrote:

> How should Impala branches be a manged?
>
> Today, most of our new development happens on trunk, except when a CDH
> release is imminent. I propose we move to a time-based release model,
> where development happens on the "master" branch and every N weeks a
> commit that is passing all of the tests is tagged with a version
> number.
>
> Then we can do an actual release: http://www.apache.org/dev/release.html
>
> For big breaking changes, we could keep two branches around
> corresponding to the two versions currently being developed on.
>
> Thoughts?
>