Mailing-List: contact dev-help@impala.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@impala.incubator.apache.org
MIME-Version: 1.0
In-Reply-To: <CAC-pSX2DacqGpdorWj47px+nSjSQd9=PkdK4u4SDFQX=9=YGMQ@mail.gmail.com>
References: <CAC-pSX2t+FmD9YLO_9XcEqGKM373ye5+U610ync=XTe1a7sLaw@mail.gmail.com>
 <CAEoRBew0xB7F=gzX8t96W-BGaPt1M0mnuZtsqNihYei8oTG7xQ@mail.gmail.com>
 <CAC-pSX2DK3rkAm1tkwexRmOxMKMMiceZzo30hHuPZEKn7SG_UQ@mail.gmail.com>
 <CADZba-R+5FnhhoA0JYKDjR-3c13Rh6tBSypkdXY3D0SdEawcWQ@mail.gmail.com> <CAC-pSX2DacqGpdorWj47px+nSjSQd9=PkdK4u4SDFQX=9=YGMQ@mail.gmail.com>
From: Jim Apple <jbapple@cloudera.com>
Date: Tue, 14 Jun 2016 08:56:50 -0700
Message-ID: <CAC-pSX17gxBs+sP=vyzAiK+Yjq2EXLGkGXexp9Jsy+B430RvVg@mail.gmail.com>
Subject: Re: Branch model discussion
To: dev@impala.incubator.apache.org
Content-Type: text/plain; charset=UTF-8
archived-at: Tue, 14 Jun 2016 15:57:36 -0000

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 <jbapple@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?