Responses to several threads below, sorry in advance to folks that
with mail readers this will mess up.
On Wed, Nov 14, 2018 at 7:35 PM Andrew Purtell wrote:
>
> > Some time ago we talked about trying to get back on track for a more
> regular cadence of minor releases rather than maintenance
> Some time ago we talked about trying to get back on track for a more
regular cadence of minor releases rather than maintenance releases (like
how we did back pre-1.0). That never quite worked out for the HBase 1.y
line,
This is a bit premature to say never. I've been making steady releases of
I’ll start another thread about metrics gathering.
On Tue, Nov 13, 2018 at 8:15 AM Stack wrote:
> On Sun, Nov 11, 2018 at 8:18 PM Misty Linville wrote:
>
> > It's not great to guess about things like this.
> > We're making a big assumption that our users actually pay attention to
> >
On Sun, Nov 11, 2018 at 8:18 PM Misty Linville wrote:
> It's not great to guess about things like this.
> We're making a big assumption that our users actually pay attention to
> user@
> or more often dev@ in order to complain about a branch being retired too
> quickly in time for us to
This makes me wonder if we have, or have a way to get, analytics about the
version people are running? It's not great to guess about things like this.
We're making a big assumption that our users actually pay attention to user@
or more often dev@ in order to complain about a branch being retired
Yes. Was suggesting retiring branch-2.0 and suggesting that we throw the
troops against the branch-2.2 flank. Agree though that if there are folks
who want more releases, lets do them (please speak up if this is so). 2.0.3
will be good since it close to 2.1.1. Unless demand, 2.0.4 will likely
But, since that some users may already have their production system on
HBase-2.0.x, maybe we should consider their feelings, they are the 'first
movers'. If we retire branch-2.0 so quickly, IIRC, the branch-2.0 will be
the shortest life branch ever. I think it will hurt the feeling of those
'first
Stack, are you suggest about retiring branch-2.0? I think it is OK, since
branch-2.0 is almost the same with branch-2.1 now(except some new feature
on replication). Yes, agree that we should help out on branch-2.2. AMv2
changed a lot in branch-2, there may still have some work to do to make
Agree w/ Duo that the 2.x releases have been gated on stability watersheds
rather than features.
What else do we need to add to HBCK2 Duo (apart from a release)?
Related, I was going to work on a 2.0.3 release. It has been a while and a
bunch of good stability work has made it into branch-2.0.
Yes, agreed. My comment was more aimed at getting someone to "sign-up"
to do the work, regardless or what branch they're watching.
I'd be in favor of trying it out, see how it works. What's the worst
that happens, we re-evaluate in three months? :shruggie:
On 11/8/18 8:45 PM, Sean Busbey
Oh, typo, 'the make_rc.sh can do everything for you'
张铎(Duo Zhang) 于2018年11月9日周五 上午10:09写道：
> I think for the 2.x release the problem is that we are still busy on
> making the code stable, or speak more clearly, to make the procedure v2
> framework stable... And another big problem is lacking
I think for the 2.x release the problem is that we are still busy on making
the code stable, or speak more clearly, to make the procedure v2 framework
stable... And another big problem is lacking of HBCK2 support. These things
are all big issues which prevent people to upgrade to 2.x.
Once these
I think it just shifts the RM burden, no? Like instead of watching e.g.
branch-2.2 I instead need to watch branch-2.
On Thu, Nov 8, 2018, 17:28 Josh Elser I think what I'd be concerned about WRT time-based releases is the
> burden on RM to keep the branch in a good state. Perhaps we need to not
This is an important topic. Thanks for bringing it up.
For what it’s worth, I found the “release train” to work pretty well for
patch releases from 1.1. That was only possible because of the stability of
that branch. After the first couple releases, devs were pretty good about
honoring the “bug
I think what I'd be concerned about WRT time-based releases is the
burden on RM to keep the branch in a good state. Perhaps we need to not
push that onto an RM and do better about sharing that load (looking in
the mirror).
However, I do like time-based releases as a means to avoid "hurt
Hi folks!
Some time ago we talked about trying to get back on track for a more
regular cadence of minor releases rather than maintenance releases
(like how we did back pre-1.0). That never quite worked out for the
HBase 1.y line, but is still something we could make happen for HBase
2.
We're
16 matches
Mail list logo
