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
