hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: [DISCUSSION] Sorting out issues for 0.96 for (eventual) release
Date Wed, 09 Jan 2013 16:09:44 GMT
On Wed, Jan 9, 2013 at 4:45 AM, Nicolas Liochon <nkeywal@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,

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