accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: 1.6.0 Feature Freeze
Date Sat, 02 Nov 2013 06:14:05 GMT
Here's links to the jql you gave above:

http://s.apache.org/accumulo-ff-1.6.0
http://s.apache.org/accumulo-ff-1.6.0-remaining

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii


On Sat, Nov 2, 2013 at 12:34 AM, John Vines <vines@apache.org> wrote:
> Here's the query for everything 'feature freeze'-y -
> project = ACCUMULO AND fixVersion = "1.6.0" AND status not in (Resolved,
> "Patch Available") AND issuetype != bug AND component not in (Docs) ORDER
> BY priority DESC
>
> But going forward, this is the one I'll be referencing-
> project = ACCUMULO AND fixVersion = "1.6.0" AND status in (Open, "In
> Progress", Reopened, "Patch Available")
>
> That said, all the remaining tickets are either patch available, bugs,
> documentation, or subtasks of features which are in, either via commit or
> review board. So, running with the review board definition + defining
> feature freeze as a major feature freeze (which was really the point, to
> prevent a lot of big code changes close to/during testing), I think we hit
> our goal. There are a few questionable sub-tasks out there which really do
> need to be addressed in the coming week, but I think a week of feature
> 'clean up' is acceptable, especially relative to last release (sorry,
> again).
>
> I don't think requires any sort of vote as it's not so much a rules change
> as it is asking the developer community to hold off a little bit on
> challenging certain features until they've been polished a bit more.
>
> That said, a week from today I'm going to start using the defined and voted
> on release processes for challenging incomplete features. And my definition
> of complete is based solely on JIRA / review board, so keep things up to
> date please. Then this should give us plenty of time for the
> bughunting/polishing of the overall release.
>
> John
>
> On Fri, Nov 1, 2013 at 10:32 PM, Josh Elser <josh.elser@gmail.com> wrote:
>
>> 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 <vines@apache.org> wrote:
>>>
>>>> On Thu, Oct 31, 2013 at 4:59 PM, Sean Busbey <busbey@cloudera.com>
>>>> wrote:
>>>>
>>>>  On Thu, Oct 31, 2013 at 3:45 PM, John Vines <vines@apache.org> 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<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<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<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
>>>>>
>>>>>

Mime
View raw message