hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Drob <md...@apache.org>
Subject Re: DISCUSSION: "branch RM" roles for non-released branches branch-1, branch-2, and master
Date Thu, 08 Mar 2018 00:40:32 GMT
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

On Wed, Mar 7, 2018 at 5:12 PM, Stack <stack@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>*

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message