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 <[email protected]> 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 <[email protected]> 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 <[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<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 >>>>> >>>>>
