So to sum up my understanding of the idea: - More minor/major releases, less patch releases - From logistic perspective, we are moving from a model where few people are locked in for long time (4-5 RMs locked in for ~10 patch releases) to a model where more people are locked in for less time (more minor releases -> more RMs, but hopefully only 4-5 patch releases) with 2-3 CT (care takers).
Just trying to put some numbers to make sure all are on same page. We can try it. Idea sounds good to me. @andrew: Is there any other community which follows this/similar pattern? How's their experience? Do users like/hate more minor releases? -- Appy On Thu, Mar 8, 2018 at 8:02 AM, Andrew Purtell <apurt...@apache.org> wrote: > > > β > For eg. Andrew will caretake branch-1.4, Stack will caretake branch-2.0 > > Not as I originally proposed. In this example, Andrew will caretake > branch-1 and Stack will caretake branch-2. Andrew and Stack will be making > more minor release branches more often and patch releases will become less > frequent. For example, I'm going to be done with branch-1.4 in six months > and on to branch-1.5. (Hypothetically.) Anyone is welcome to RM those > branch-x.y. As long as someone is actively RMing branch-x.y it stays alive. > That's how we'd come to a consensus on what is long term stable. > > > On Wed, Mar 7, 2018 at 5:55 PM, Apekshit Sharma <a...@cloudera.com> wrote: > > > I like the thought, continuing to brainstorm.... > > In this method, the following holds true, right? > > - Care taking "branch-X.Y" will require least effort and will by default > > fall onto the shoulders of RM for X.Y version. > > ββ > > For eg. Andrew will caretake > > branch-1.4, Stack will caretake branch-2.0, and so on. > > - Care taking "branch-X" will require a bit more effort and it's > uncertain > > how to assign one to such branches. > > One way is, whoever will do the next minor release can own it. But the > > caveat in that is, > > a) It's hard to find RMs as such, this may make it more difficult since > > one will have to own up the task much ahead in advance. Or, the effect > > could be opposite, since this way gives more heads up for carrying out RM > > responsibilities. Would be certainly interesting to see how it works out. > > b) For branch-1 which might be close to finish, there's uncertainty - > > assign care taker but no future release (wasted effort?), OR, no care > taker > > until we decide that there will be future release (more like status > > quo). We can make the decision when we are at the fork. For now, seems > like > > we have one who's willing to take care of branch-1 to shepherd it towards > > 1.5.0....smile. > > > > Other way is, once can just caretake a branch without singing up to do > > the next release. > > I don't think we have to choose one way or another (in fact, we might > not > > have the luxury) and instead, can go with the flow (i.e. as contributions > > show up). > > > > - Care taking for "master": The most onerous task since almost everything > > goes in it - all patches, new features, bug fixes, test breaking changes, > > etc. Defining 'care taking' of this branch will be a bit more difficult. > > Might be too big for single person, maybe round robin the task among > > committers/contributors (generates another opportunity for contributors > to > > sparkle and become committers)? > > Unless this one is solved, we are not rectifying the problem mentioned by > > Stack previously - "...avoiding the hell that was 2.0.0 where its taken > > near on a year to stabilize (first alpha was last year) because it has > over > > 5k JIRAs in it". > > > > To end on positive note, i volunteer to care take branch-2 once 2.0 GA is > > out. > > > > -- Appy > > > > On Thu, Mar 8, 2018 at 6:10 AM, Mike Drob <md...@apache.org> wrote: > > > > > If somebody volunteers to be the caretaker for 1.5.0, is there an > > implicit > > > expectation that they would take on the responsibilities for branch-1 > as > > > well? > > > > > > On Wed, Mar 7, 2018 at 5:12 PM, Stack <st...@duboce.net> wrote: > > > > > > > (Moving discussion to DISCUSSION thread from "NOTICE: made branch-2.0 > > > > from..." -- my fault for starting it in wrong place) > > > > > > > > A while back, Andrew made a PROPOSAL for 'branch RM's [1]. I like > this > > > > suggestion. I see it as a means of avoiding the hell that was 2.0.0 > > where > > > > its taken near on a year to stabilize (first alpha was last year) > > because > > > > it has over 5k JIRAs in it; RMs can help keep their branch tidy and > > free > > > of > > > > flotsam. > > > > > > > > Andrew added more to his notion of 'branch RM' over in the NOTICE > > > thread. I > > > > repeat it below: > > > > > > > > "βFor a while leading up to 1.4.0 I was effectively the branch-1 RM > in > > > > practice. Slacked off a bit since, but I'd like to continue with that > > if > > > > you're agreeable. I think that branch RM role involves informally: > > > > - Keeping an eye on commits to branch. Periodic review of recent > > commits. > > > > Not acting as a gate on commits and not needing to be pinged or in > the > > > loop > > > > for every commit, except perhaps for short periods of time around > > > branching > > > > for new minors. > > > > - Keeping an eye on test stability. Undertaking get well projects > like > > > > bisecting and reverting offending commits to resolve test suite > decay. > > > > - Periodically kicking off new minor releases. Depends on branch and > > need > > > > for what's on deck." > > > > > > > > Interested in what folks think. > > > > St.Ack > > > > > > > > 1. *https://lists.apache.org/thread.html/ > > 247697bcfb97adeeec2d14241856ca > > > > 7a77a167c9efe0dbc83b0a746f@%3Cdev.hbase.apache.org%3E > > > > <https://lists.apache.org/thread.html/247697bcfb97adeeec2d14241856ca > > > > 7a77a167c9efe0dbc83b0a746f@%3Cdev.hbase.apache.org%3E>* > > > > > > > > > > > > > > > -- > > > > -- Appy > > > > > > -- > Best regards, > Andrew > > Words like orphans lost among the crosstalk, meaning torn from truth's > decrepit hands > - A23, Crosstalk > -- -- Appy
