On Wed, Jan 9, 2013 at 4:45 AM, Nicolas Liochon <nkey...@gmail.com> wrote:
> It would be great to have a release soon. > The migration will require some work from the user point of view: if I'm > not wrong it's mandatory to rewrite the coprocessors and the filters (even > if it's not mandatory, it seems to be a reasonable task to include in the > migration). > Just endpoint cps (IIUC). > For this reason, I think there should be a stable-enough beta release that > people could use to start this migration. Our contract would be to keep the > coprocessor & filter API stable between the beta and the RC. But it won't > be to have no regression nor new features between the beta & the RC. And > this would send a signal "now we're focusing on the delivery". > > Beta sounds like a good idea given the amount of change in 0.96. Could make one soon, as soon as we branch. I could take care of this if folks like the idea. Call it 0.96.0-beta? For MTTR, there are still a lot of stuff to be done, but it's a never > ending task. There's my work on assignment, but I don't break the existing > logic, and it's finishing. MTTR is bigger than that, but there will be new > ideas, so if we wait for the end of this we will never deliver. And real > world feedback is valuable. So I setting an arbitrary target would be > acceptable for this specific point imho (objective for MTTR beeing to be > always under 1 minute for total recovery time). > > Agree on the above. MTTR is much improved in 0.96 as is (Can we close HBASE-7007?). We should get the improvements out in the field. > May be some stuff could make it as a contrib as well (i.e. secondary > indexes)? > Not mad about carrying contribs in hbase. We've been there. No problem pointing/advertising dependent repositories and doing anything in core to facilitate dependent/supporting work but would rather not carry the stuff in core; in general contribs start to become a drag on core dev. Good on you N, St.Ack
