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 >>
