> 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. I love the idea! The previous release schedule exhausts RMs and increase fragmentation of HBase.
So if no other people try to RM the MINOR release, the following will come true 1) no PATCH release 2) a MINOR release per 6 months 3) a MAJOR release per 2.5 years (6 months * 5 minor releases, it means we release 3.0 and 2.4/2.5 at the same time) In this scenario, 3 branch RMs manage our all releases. (branch-1, branch-2, and master) If someone(PMC, committer, or ?) want to RM the minor release(Only latest minor release can be RM? Or we can active any retired MINOR release?) 1) a patch release per 2 week (6 months / 10 patch releases, or issue-trigger?) On 2018/03/08 02:32:24, 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 >
