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
