hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <andrew.purt...@gmail.com>
Subject Re: Proposal: Create "branch RM" roles for non releasing branches branch-1, branch-2 (when it exists), and master
Date Sat, 14 Jan 2017 22:02:23 GMT
Thanks everyone for the discussion. I'll informally watch branch-1. Planning on monthly passes
for cherry picks and release testing as I did for 0.98, but in this case the output will be
nonrelease snapshots. Release RMs will not see pick backs from me. The changes you can expect
is reverts if we something problematic and it has not gone out in a release yet. Looking forward
to a productive LTS of branch-1. 


> On Jan 11, 2017, at 1:43 PM, Enis Söztutar <enis@apache.org> wrote:
> 
> I was thinking in similar lines that the RM for 1.X which is the next one
> would be managing branch-1, but I am also concerned about the large gap in
> terms of timing. For example, unless we are close to 1.4, an 1.4 RM will
> not materialize.
> 
> So, I am in favor of having an informal branch-1 RM that will work with the
> 1.x RMs. An +1 for Andrew for that role.
> 
> Enis
> 
> On Wed, Jan 11, 2017 at 1:17 PM, Andrew Purtell <andrew.purtell@gmail.com>
> wrote:
> 
>> We could do it that way but there would be nobody promising to watch
>> branch-1 for any length of time. I'd like to do that. We could do this
>> alternative for branch-2. And it makes sense once we have this sorted to
>> write down what we'd like to do.
>> 
>> 
>>> On Jan 9, 2017, at 3:27 PM, Nick Dimiduk <ndimiduk@gmail.com> wrote:
>>> 
>>> Somewhat late to the reply --
>>> 
>>> Does it make sense, for branch-1, to have the person planning to RM the
>>> next minor release act as the RM for the major-level branch? That person
>>> would hand responsibility to the next minor RM upon cutting the
>>> stabilization branch.
>>> 
>>> This could be applied to master/branch-2 as well, but the further away we
>>> get from a target release date, the more nebulous the RM role becomes.
>>> 
>>>> On Fri, Jan 6, 2017 at 5:07 PM Andrew Purtell <apurtell@apache.org>
>> wrote:
>>>> 
>>>> HBasers,
>>>> 
>>>> 
>>>> 
>>>> I would like to propose extending our informal "branch RM" concept just
>> a
>>>> 
>>>> bit to include the nonreleasing branches like branch-1, branch-2 (when
>> it
>>>> 
>>>> exists), and master. These branches are where all commits are made
>> passing
>>>> 
>>>> through down to the releasing branches targeted for the change (like,
>>>> 
>>>> branch-1.1, branch-1.2, branch-1.3, etc.)
>>>> 
>>>> 
>>>> 
>>>> The releasing branches all have their own RM. I assume that RM is
>>>> 
>>>> diligently monitoring its state, by way of review of commit history,
>>>> 
>>>> occasional execution of the unit test suite, occasional execution of the
>>>> 
>>>> integration tests, and has perhaps some automation in place to help with
>>>> 
>>>> that on a nightly or weekly basis. No matter, let's assume there is a
>>>> 
>>>> nonzero level of scrutiny applied to them, which leads to feedback to
>>>> 
>>>> committers about inappropriate commits via compat guidelines, commits
>> which
>>>> 
>>>> have broken unit tests, or other indications of quality or functional
>>>> 
>>>> concerns.  I think it would improve our overall velocity as a project
>> if we
>>>> 
>>>> could also have volunteers tending the development branches upstream
>> from
>>>> 
>>>> the releasing branches. Less work would fall to the RMs tending the
>> release
>>>> 
>>>> branches if a common troublesome commit can be caught upstream first. In
>>>> 
>>>> particular I am thinking about branch-1.
>>>> 
>>>> 
>>>> 
>>>> I would like to volunteer to become the new RM for branch-1, to test and
>>>> 
>>>> refine my above proposal in practice. Unless I hear objections I will
>>>> 
>>>> assume by lazy consensus everyone is ok with this experiment.
>>>> 
>>>> 
>>>> 
>>>> What this would mean:
>>>> 
>>>> 
>>>> 
>>>>  - JIRAs like "TestFooBar is broken on branch-1" will show up sooner,
>> and
>>>> 
>>>>  more likely with fix patches
>>>> 
>>>>  - Semiregular performance reports on branch-1 code as of date X/Y/Z,
>> can
>>>> 
>>>>  compare with earlier reports for trending
>>>> 
>>>>  - Occasional sweep through master history looking for appropriate
>>>> 
>>>>  candidates for backport to branch-1, execution of said backport
>>>> 
>>>>  - Occasional 1B row ITBLL torture tests, probably if failure with
>> bisect
>>>> 
>>>>  back to commit that introduced instability
>>>> 
>>>> 
>>>> 
>>>> What this does not mean:
>>>> 
>>>> 
>>>> 
>>>>  - The branch-1 RM will not attempt to tell other branch RMs what or
>> what
>>>> 
>>>>  not to include in their release branches
>>>> 
>>>>  - The branch-1 RM won't commit anything backported from master to any
>> of
>>>> 
>>>>  the release branches; it will continue to be up to the release branch
>>>> RMs
>>>> 
>>>>  what they would or would not like to be included
>>>> 
>>>> 
>>>> 
>>>> ​Also, I don't see why I couldn't spend some time looking at master now
>> and
>>>> 
>>>> then.
>>>> 
>>>> 
>>>> 
>>>> I am going to assume our current co-RM team for branch-2 would maybe do
>>>> 
>>>> something similar for branch-2, once it materializes.
>>>> 
>>>> 
>>>> 
>>>> Thoughts? Comments? Concerns?
>>>> 
>>>> ​
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> 
>>>> Best regards,
>>>> 
>>>> 
>>>> 
>>>>  - Andy
>>>> 
>>>> 
>>>> 
>>>> If you are given a choice, you believe you have acted freely. - Raymond
>>>> 
>>>> Teller (via Peter Watts)
>>>> 
>>>> 
>> 

Mime
View raw message