> per an old Andrew Purtell suggestion that we do a left-shift on version
numbers when it comes to RM oversight
> I can't find his email. Please add to this thread if any of you know what
I'm on about (smile).
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.
On Wed, Mar 7, 2018 at 10:41 AM, Stack <st...@duboce.net> wrote:
> Please get my approval committing to branch-2.0. I'm trying to keep the
> branch stable as we head toward our first 2.0.0 release candidate.
> Related, please do not treat branch-2 as a dumping ground going forward.
> I'll try and keep an eye on it too (per an old Andrew Purtell suggestion
> that we do a left-shift on version numbers when it comes to RM
> oversight). Only bug-fixes and pre-discussed features should go on
> branch-2 to ship in minor 2.x releases. Master and the our future hbase3
> is where the new stuff should be targeted.
> 1. The only branch-2 'feature' I know of currently is the serial
> replication work Duo and crew are currently working on.
> 2. I can't find his email. Please add to this thread if any of you know
> what I'm on about (smile).
Words like orphans lost among the crosstalk, meaning torn from truth's
- A23, Crosstalk