Devaraj Das 2013-02-06, 21:53
Stack 2013-02-06, 22:29
Andrew Purtell 2013-02-06, 23:11
Stack 2013-02-06, 23:26
Andrew Purtell 2013-02-06, 23:29
Nicolas Liochon 2013-02-07, 08:41
Stack 2013-02-07, 20:54
-Re: [DISCUSSION] Sorting out issues for 0.96 for (eventual) release
Jonathan Hsieh 2013-02-06, 22:11
I'm am in general +1 for this scope lock and branching soon. There
are a whole lot of non-trivial refactors/features that are close to
commit but I think will cause pain as we try to stabilize. And with
some of the internals changes that are being proposed (new fs layout)
and have been prototyped (removing root, etc) it looks like 0.96 will
be the first singularity.. to be followed by another singularity
called 0.98 (or 2.0)
Can someone summarize where we are at with the RPC currently? The KV
stuff is to make sure we don't regress from core get/put perf
characteristics of 0.94 right?
Snapshot work is currently bogged down trying to get tests to pass on
a snapshot+trunk merge (see HBASE-7290 for issues). :(. Once I get a
clean run there I plan on formally posting the branch for review and
doing the real cluster testing on the merge snapshot+trunk branch
instead of just the snapshot branch. On this front, we've got the
failures categorized and at the moment have hacks (some unacceptable,
but pointing towards root cause) to fix all but one of these failures.
On Wed, Feb 6, 2013 at 1:53 PM, Devaraj Das <[EMAIL PROTECTED]> wrote:
> Stack, did you lose the bet to JD yet :-)
> But seriously, should we consider branching 0.96 now? I know there are
> quite a few blockers/criticals but they can be fixed/merged even after
> the branching. Given that we want to release sooner a 0.96, I think it
> makes sense to branch sooner as well and lock the scope somewhat (that
> will also hopefully avoid creating more new blockers).
> What is the absolute list of things we must wait for before branching?
> Should it be only Snapshots? Should it be RPC, KeyValue serialization
> & Snapshots. There are many other things being developed in trunk and
> many of them are probably okay for 0.96 as well if they are completed
> on time. But I think we should put a stake on the ground and consider
> a date for branching and work towards achieving that. After that it'd
> be up to the RM to consider something for 0.96 or not.
> Should we aim for Feb 28 as the date for branching. Then we can have
> an RC in approximately 1.5 - 2 months (April mid-end), and it would
> probably be in line with what Andrew was thinking about when he
> started this thread. Does it sound too aggressive?
> On Thu, Jan 10, 2013 at 4:02 PM, Stack <[EMAIL PROTECTED]> wrote:
>> We tried to doc our versioning up on wiki:
>> Its out of date and needs moving into the ref guide but there is a
>> we could reuse that Todd did for 89, the "Development Release", explaining
>> (Chatting with Todd, he suggested not waiting for 0.96 to branch but just
>> branch first 0.95 from trunk -- we could do that too though I wouldn't mind
>> the rpc stabilizing first...)
>> On Thu, Jan 10, 2013 at 3:38 PM, Andrew Purtell <[EMAIL PROTECTED]> wrote:
>>> On Thu, Jan 10, 2013 at 3:34 PM, Enis Söztutar <[EMAIL PROTECTED]> wrote:
>>> > I dont see why odd/even is better than adding -dev/-beta suffix,
>>> > [...] If historically, 0.89/0.90 worked well, we
>>> > might as well go with it.
>>> Right, the notion is to just do what we did before, having had this
>>> discussion previously, to avoid going over this again.
>>> Best regards,
>>> - Andy
>>> Problems worthy of attack prove their worth by hitting back. - Piet Hein
>>> (via Tom White)
// Jonathan Hsieh (shay)
// Software Engineer, Cloudera
// [EMAIL PROTECTED]
Stack 2013-02-06, 22:52