I see, that is indeed undesirable.
Tho based on this discussion there's a bunch of good features that users want
that won't fit the criteria for #1 and #2. So allowing a backport of the few
that can fit into the criteria shouldn't significantly affect future release
from trunk. This way we can have some progress on some features.
On Monday, March 21, 2016 10:23 AM, Sean Busbey <bus...@cloudera.com> wrote:
Hadoop's trunk branch hasn't had a release in a very very long time. So it
continues to accumulate changes that aren't in a release while folks drive
their particular desired features back into branch-2.
On Mon, Mar 21, 2016 at 12:01 PM, Francis Liu <tof...@apache.org> wrote:
To summarize so far it seems the concerns for backporting are:
1. compatibility - api, wire, rolling upgradeabability2. stability -
destabilizing code and deploys for those that don't want the new feature
Is there anything else?
Elliot what happened to hadoop? Is it neither of the two?
Francis
On Thursday, March 17, 2016 12:01 PM, Enis Söztutar <e...@apache.org> wrote:
As long as there is interest in doing the backport work, maintaining and
experimenting with the feature on an actual release (which seems to be the
case for RSGroups and Spark at least) and keeping the code base for
branch-1 stable, there is no reason not to backport. RsGroups (and I
believe Spark support as well) is marked experimental in release notes
which means that there is some room for our client-visible guarantees.
2.0 has it's own timeline and feature set and will come in time. Of course
anybody can propose to cut a release and push for getting it sooner rather
than later. We should all help the effort, but realistically, even if after
2.0 is released, there will be people running 1.x for years after that.
Enis
On Thu, Mar 17, 2016 at 11:28 AM, Mikhail Antonov <olorinb...@gmail.com>
wrote:
> >>>"Why MOB and RegionServer Groups should be in a new major version and
> stuff
> like the new RPC queue (HBASE-15136), date based tiered compactions
> (HBASE-15181), special handling for system tables WALs (HBASE-13557), keep
> table state in meta (HBASE-13017) or the Region Normalizer (HBASE-13103)
> are considered for or already in 1.x?"
>
> To me the differentiator would be "how much does it change the codebase
> around". If all/most of code change is the code which is new/ignored when
> feature is turned off, and by default it's off until well-tested by various
> users - then it should be fine to include. In the list above MOBs probably
> don't satisfy that, Spark and RS Groups probably do.
>
> If we make 2.0 release with just Mobs and RS Groups, that would mean new AM
> would have to be postponed to 3.0? What about procsV2? Although we would
> want rolling upgrade to 2.0, still it's our chance to release something
> big, invasive and new (since as was mentioned, the user expectation anyway
> would be that in new major version some incompatibilities would be present
> and some migration may be required)?
>
> -Mikhail
>
> On Thu, Mar 17, 2016 at 7:48 AM, Matteo Bertozzi <theo.berto...@gmail.com>
> wrote:
>
> > Why MOB and RegionServer Groups should be in a new major version and
> stuff
> > like the new RPC queue (HBASE-15136), date based tiered compactions
> > (HBASE-15181), special handling for system tables WALs (HBASE-13557),
> keep
> > table state in meta (HBASE-13017) or the Region Normalizer (HBASE-13103)
> > are considered for or already in 1.x?
> >
> > to me, and probably most of the users, a new Major version means that
> APIs
> > will break, wire may break, there may be an upgrade of some sort and so
> on.
> > which is not true for MOB and RS groups.
> >
> > In case we do a major for RS groups and Mob will that still based on the
> > 1.x branch?
> >
> > On Wed, Mar 16, 2016 at 11:23 PM, Andrew Purtell <
> andrew.purt...@gmail.com
> > >
> > wrote:
> >
> > > I remember explicitly saying I was not against a backport of the MOB
> > > feature. You are misrepresenting my position a bit. Sure, I'm a
> skeptic.
> > > Not a big deal because I don't think we can or should seek a blanket
> > rule.
> > > Sometimes a feature will have sufficient interest and applicability
> that
> > a
> > > backport is worth considering, and then there's a question of what kind
> > of
> > > risk the changes envisioned carry. RS groups as implemented are low
> risk.
> > > Meanwhile MOB is highly invasive. I think RS groups would have two
> large
> > > production users soon after introduction into branch-1. I'm not sure
> > about
> > > MOB. They are worth consideration on their own merits and on user
> demand
> > > for them.
> > >
> > > Another thing we could do is get 2.0 started right now. Whatever major
> > > that doesn't make the cut could go into 3.0. I think the requests for
> > these
> > > backports are coming because there is no near time horizon for a 2.0
> > > release. So set it soon?
> > >
> > >
> > > > On Mar 16, 2016, at 9:27 PM, Elliott Clark <ecl...@apache.org>
> wrote:
> > > >
> > > > On Wed, Mar 16, 2016 at 6:26 PM, Andrew Purtell <
> > > andrew.purt...@gmail.com>
> > > > wrote:
> > > >
> > > >> Because I for one might well want to run RS groups in production
> with
> > > >> branch-1 code without waiting for or dealing with the other stuff
> > > coming in
> > > >> any 2.0.
> > > >
> > > >
> > > > This is the same email that I sent for MOB. Which you agreed with
> then.
> > > But
> > > > not now. There's nothing substantively different about this feature
> > that
> > > > makes it different from any other feature. It's a large change that
> > > wasn't
> > > > there in 1.X line.
> > > >
> > > > I would like backups, and procedure v2 in 1.x. However even if it
> > landed
> > > > tomorrow they shouldn't be back ported as it's a large feature that's
> > not
> > > > ready. If we want anyone to ever upgrade major versions, then the new
> > > > features have to come along with the new apis. Other wise we will end
> > up
> > > in
> > > > the same state that Hadoop has.
> > >
> >
>
>
>
> --
> Thanks,
> Michael Antonov
>
--
busbey
