hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Todd Lipcon <t...@cloudera.com>
Subject Re: putting a border around 0.92 release
Date Mon, 28 Feb 2011 22:00:28 GMT
On Sat, Feb 26, 2011 at 2:24 PM, Jean-Daniel Cryans <jdcryans@apache.org> wrote:
> Woah those are huge tasks!
> Also to consider:
>  - integration with hadoop 0.22, should we support it and should we
> also support 0.20 at the same time? 0.22 was branched but IIRC it
> still has quite a few blockers.
>  - removing heartbeats, this is in the pipeline from Stack and IMO
> will have ripple effects on online schema editing.
>  - HBASE-2856, pretty critical.
>  - replication-related issues like multi-slave (which I'm working on),
> and ideally multi-master. I'd like to add better management tools too.
> And lastly we need to plan when we want to branch 0.92... should we
> target late May in order to be ready for the Hadoop Summit in June?
> For once it would be nice to offer more than an alpha release :)

In my view, we can do one or the other: either it's a feature-based
release, in which case we "release it when it's done", or it's a
time-based release, in which case we release at some decided-upon time
with whatever's done.

I personally prefer time-based releases, though we need to make sure
if we decide to do this that any large destabilizing (or half
complete) features are guarded either by config flags or are developed
in a branch. Thus trunk stays relatively releasable at all times and
we can be pretty confident we'll hit the decided-upon timeline.

Looking back at the 0.90 release, we got caught in a bind because we
were trying to do both feature-based (new master) and time-based (end
of 2010).

So, my vote is either:
plan a: hybrid model - 0.91.X becomes a time-based release series
where we drop trunk once every month or two, and 0.92.0 is gated on
plan b: strict time-based: we release 0.92.0 around summit, and lock
down the branch at least a month or so ahead of time for bugfix only.



> On Sat, Feb 26, 2011 at 12:34 PM, Andrew Purtell <apurtell@apache.org> wrote:
>> Stack and I were chatting on IRC about settling with should get into 0.92 before
pulling the trigger on the release.
>> Stack thinks we need online region schema editing. I agree because per-table coprocessor
loading is configured via table attributes. We'd also need some kind of notification of schema
update to trigger various actions in the regionserver. (For CPs, (re)load.)
>> I'd also really like to see some form of secondary indexing. This is an important
feature for HBase to have. All of our in house devs ask for this sooner or later in one form
or another. Other projects have options in this arena, while HBase used to in core, but no
longer. We have three people starting on this ASAP. I'd like to at least do co-design with
the community. We should aim for 'simple and effective'.
>> There are 14 blockers: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+HBASE+AND+fixVersion+%3D+%220.92.0%22+AND+resolution+%3D+Unresolved+AND+priority+%3D+Blocker
>> Additionally, 22 marked as critical: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+HBASE+AND+fixVersion+%3D+%220.92.0%22+AND+resolution+%3D+Unresolved+AND+priority+%3D+Critical
>> Best regards,
>>    - Andy
>> Problems worthy of attack prove their worth by hitting back.
>>  - Piet Hein (via Tom White)

Todd Lipcon
Software Engineer, Cloudera

View raw message