Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo, mail # dev - 1.6.0 Feature Freeze


Copy link to this message
-
Re: 1.6.0 Feature Freeze
Josh Elser 2013-11-02, 02:32
Ditto to the filter links (I think Jira makes this harder than you
anticipate if memory serves).

Everything outlined here looks good to me. +1, Mr. John "Release
Manager" Vines.

On 11/1/13, 7:02 PM, Christopher wrote:
> Those filter links don't seem to work for me.
> BTW, +1 on proposal, with my suggestions, if that vote is still
> running and you didn't already count me.
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Thu, Oct 31, 2013 at 7:14 PM, John Vines <[EMAIL PROTECTED]> wrote:
>> On Thu, Oct 31, 2013 at 4:59 PM, Sean Busbey <[EMAIL PROTECTED]> wrote:
>>
>>> On Thu, Oct 31, 2013 at 3:45 PM, John Vines <[EMAIL PROTECTED]> wrote:
>>>
>>>>
>>>> All of your comments make sense to me. Unfortunately we're a bit stuck in
>>>> the latter category. Going forward we can make steps as a community to
>>> help
>>>> prevent it, but that doesn't change this release. And beside issue of
>>>> pulling out an incrementally committed feature, pulling out features
>>> lends
>>>> the potential for a release to be insubstantial.
>>>>
>>>>
>>> There are 149 non-duplicate issues resolved marked for 1.6.0 that aren't
>>> marked for a 1.5.x series[1].
>>>
>>> That a good deal, though I admittedly don't know how substantial they are,
>>> and I don't have a sense for how many would be *need* to be pulled out as
>>> part of a major feature revert.
>>>
>>>
>>>> So for the sake of the 1.6.0 release, what do we think we should do about
>>>> the sub-tasks for added/expected features? Particularly ones deemed
>>>> requisite for that feature to hit the mainline?
>>>>
>>>
>>> Ultimately, if you're the release manager you get to decide. You can just
>>> take a very permissive view on how far along things posted to review board
>>> need to be at the start. Or a permissive view on what constitutes an update
>>> "critical" for the release.
>>>
>>> I think we all want to avoid the ~5 months it took to get through RC on
>>> 1.5, but I'd be happy with even the incremental improvement we'd have by
>>> implementing Chris' suggestion on a review board choke point starting at
>>> deadline. Even if things drag on past a week, the patches that come out of
>>> those review boards will likely be far better organized than the frantic
>>> updates we saw last time.
>>>
>>> Do we have a prioritized list yet? An idea of what the assigned people
>>> think they'll hit by tomorrow night? A good list of gaps would help a great
>>> deal in this discussion.
>>>
>>>
>>>
>> https://issues.apache.org/jira/browse/ACCUMULO-1832?filter=12325665
>> This is the filter I'm going by. I'm running with Christopher's suggestions
>> to count things in review board as "in". Bugs are scoped as as they are
>> bugs and more will be encountered as we test features, so they're still
>> fair game. There is a discussion we should have post feature freeze for
>> establishing guidelines for code freeze, etc. more concretely (we have this
>> conversation every time, don't we?). But for now, I'm on feature freeze. Of
>> those, https://issues.apache.org/jira/browse/ACCUMULO-1832?filter=12325666 are
>> all the sub-tasks (though some should also qualify as bugs). For
>> convenience, non-sub-tasks are
>> https://issues.apache.org/jira/browse/ACCUMULO-1000?filter=12325667 . Also
>> worth noting that there's at least one parent task held open by nothing but
>> Documentation, so there's a little less than the total here too.
>>
>> I tried to prioritize tickets as well, as there are plenty left which I
>> think are okay to slip, but I'm uncertain of a lot of their statuses
>> because they are owned by people. Roughly, I would say that the ones I'm
>> most concerned about falling outside the RB guidelines are the top half of
>> the sub-tasks, mostly due to the outcome of the features those sub-tasks
>> are part of.
>>
>>
>>
>>> [1]: http://bit.ly/18H9jpx
>>>
>>> --
>>> Sean
>>>