The end of July is upon us.  I intend to cut a 0.95.2 next weekend and
0.95.2 will be 0.96.0 but for bug fixes and migration polish.  No more
'features' will be allowed after next weekend.



I have done some moving around of hbase 0.95.2 issues [1] to reflect what
the priorities are for this week (to my mind).  It is all about polish, bad
bugs, unit test failures, and packaging/publishing/build issues.

I'll be working on the blockers this week [2].  A few are in need of
reviews; e.g. "HBASE-3787 Increment is non-idempotent but client retries
RPC".  Feel free to take over any blockers if you'd like to help out: e.g.
"HBASE-7386 Investigate providing some supervisor support for znode
deletion"

Criticals [3] are mostly just unit test issues that are probably fixed by
now and another few that are patches in need of test/review: e.g.
"HBASE-8874 PutCombiner is skipping KeyValues while combining puts of same
row during bulkload" and "HBASE-8778 Region assigments scan table directory
making them slow for huge tables".
 "HBASE-6127 TestAtomicOperation#testMultiRowMutationMultiThreads
occasionally fails" is a bad one in need of attention.  Again, if up for
helping out, be our guest.

There are some great patches hanging out in the priority major issues
section that are patch available that could be committed but for want of
review: e.g. "HBASE-8369 MapReduce over snapshot files".

Regards the big features that are racing to make the 0.96 cutoff -- namely
namespaces, tags, and serialization lib -- as I see it, Francis needs
reviews if namespaces are to make it, tags ditto, and the serialization
libs are nice-to-have auxillaries that can come in at any time.  If not
done by the end of this week, then as I see it, these features do not make
the cut.

Unit tests are mostly passing.  The problematics are being worked on (e.g.
JD is on the replication set -- it likely a real problem rather than a
flakey test).

How's the above sound?
St.Ack

P.S. It is late but if folks want to meet this week to hack in patches
together, just say.  I could organize an afternoon or day if you all think
it would be a good idea.

1.
https://issues.apache.org/jira/browse/HBASE/fixforversion/12320040#selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel
2.
https://issues.apache.org/jira/issues/?jql=project%20%3D%20HBASE%20AND%20fixVersion%20%3D%20%220.95.2%22%20AND%20resolution%20%3D%20Unresolved%20AND%20priority%20%3D%20Blocker%20ORDER%20BY%20key%20DESC
3.
https://issues.apache.org/jira/issues/?jql=project%20%3D%20HBASE%20AND%20fixVersion%20%3D%20%220.95.2%22%20AND%20resolution%20%3D%20Unresolved%20AND%20priority%20%3D%20Critical%20ORDER%20BY%20key%20DESC



On Tue, Jul 9, 2013 at 1:14 PM, Stack <st...@duboce.net> wrote:

> I am shooting for end of July for 0.96 being 'complete'.   I would like to
> make a 0.96 release in August.  We have some criticals outstanding but I
> think we could ship even if these are not fixed in time (excepting
> migration polish and of course remaining build fixes).  See [1.] for the
> current list of issues.  Please re-prioritize issues as you see fit (or
> better, move issues out of 0.95.2 if you do not think they will be done in
> time).
>
> What to do with namespaces -- the last 0.96 'feature' -- given the above
> timeline?  Currently it is a massive patch out on a branch.  It is still
> not done, in want of review, and the author is going on holidays for a few
> weeks soon.  My thinking as of now, going by the rate of change over the
> last few weeks and estimating what is yet to be done, is that namespaces
> will not make it.  I am willing to be convinced otherwise but that is how
> it looks to me currently.
>
> I am going to start just disabling flakey unit tests in 0.95 from here on
> out.  When folks get the itch, they can fix at leisure first on trunk and
> then over in 0.95.
>
> What else?
>
> Thanks,
> St.Ack
>
> 1.
> https://issues.apache.org/jira/browse/HBASE/fixforversion/12320040#selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel
>
>
>
> On Mon, Jun 24, 2013 at 8:45 PM, Stack <st...@duboce.net> wrote:
>
>> (Changed the subject)
>>
>> On Mon, Jun 24, 2013 at 4:04 PM, Nick Dimiduk <ndimi...@gmail.com> wrote:
>>
>>> I want to see initial data type APIs ship out with 0.95.2. A patch for
>>> ordered byte serialization is up (HBASE-8201) and is nearing
>>> steady-state.
>>> However, sershe is the only person who's left feedback. I just posted an
>>> early patch for the data type API itself (HBASE-8693). It should get some
>>> eyes from all manor of interested parties, but I'll settle for folk from
>>> Phoenix for now.
>>>
>>>
>> It would be cool if Phoenix and Kiji fellows and any one else interested
>> would weigh in and take a look see.
>>
>> This does not strike me as something we should hold up the release for
>> though.  It looks like something that could go in at any time?
>>
>>
>>
>>> Should these tasks be escalated to criticals in order to grab attention?
>>>
>>>
>> I don't think that works going by past experience (and I don't think this
>> a blocker on 0.96)
>>
>>
>>
>>> Additional comments inline.
>>>
>>>
>> ...
>>
>>
>>
>>> Namespaces is the long pole and progress seems slow.  Do we hold up the
>>> > release for them?  How can we hurry this effort along?  Swat team
>>> descends
>>> > on Y!?
>>> >
>>>
>>> It would be a shame to not get a decision on this in for 0.96.
>>>
>>>
>> Agree.  We need to get 0.96 out though.  It has been too long.
>>
>>
>>
>>>  + Is anyone testing?  Integration tests fail on ec2 build from time to
>>> time
>>> > [2].  Our Elliott dug in on one of the failures a few days back and
>>> found
>>> > legit issue w/ no retry on admin tasks (I heart hbase-it tests).  Our
>>> unit
>>> > test story is better [3] but there are still the odd failures.
>>> >
>>>
>>> With the creation of the new list, noticing these issues is going to push
>>> further back-burner. Nannying this stuff should retain focus. I'll
>>> volunteer to track on these issues as I see them.
>>>
>>>
>> Thank you Nick.
>>
>>
>>
>>> Notice though that some of the more recent failures are caused by lack of
>>> disk space on the Jenkins build host.
>>>
>>>
>> Oh.  Missed that.  Let me dig in.
>>
>>
>> St.Ack
>>
>
>

Reply via email to