> β 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
