hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Yu <yuzhih...@gmail.com>
Subject Re: Moving 2.0 forward
Date Sat, 31 Dec 2016 20:54:00 GMT
I agree with Stephen on not branching too early.

When people come back from vacation, we can poll relevant parties on
estimate of respective project to get a sense of when would be proper time
for branching.

On Sat, Dec 31, 2016 at 12:16 PM, Stephen Jiang <syuanjiangdev@gmail.com>

> Hello, Andrew, I was a helper on Matteo so that we can help each other
> while we are focusing on the new Assignment Manager work.  Now he is not
> available (at least in the next few months).  I have to be more focused on
> the new AM work; plus other work in my company; it would be too much for me
> to 2.0 RM alone.  I am happy someone would help to take primary 2.0 RM role
> while I am still help to make this 2.0 release smooth.
> For branch-2, I think it is too early to cut it, as we still have a lot of
> moving parts and on-going project that needs to be part of 2.0.  For
> example, the mentioned new AM (and other projects, such as HBASE-14414,
> HBASE-15179, HBASE-14070, HBASE-14850, HBASE-16833, HBASE-15531, just name
> a few).  Cutting branch now would add burden to complete those projects.
> thanks
> Stephen
> On Sat, Dec 31, 2016 at 10:54 AM, Andrew Purtell <andrew.purtell@gmail.com
> >
> wrote:
> > Hi all,
> >
> > I've heard a rumor the co-RM situation with 2.0 may have changed. Can we
> > get an update from co-RMs Matteo and Steven on their availability and
> > interest in continuing in this role?
> >
> > To assist in moving 2.0 forward I intend to branch branch-2 from master
> > next week. Unless there is an objection I will take this action under
> > assumption of lazy consensus. Master branch will be renumbered to
> > 3.0.0-SNAPSHOT. Once we have a branch-2 I will immediately begin scale
> > tests and stabilization (via bug fixes or reverts of unfinished work) and
> > invite interested collaborators to do the same.
> >
> >
> >

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