A few comments inline below. Tom On Tue, Jun 14, 2016 at 4:56 PM, Jim Apple <[email protected]> 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 <[email protected]> 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?
