accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <>
Subject Re: 1.6.0 Feature Freeze
Date Fri, 01 Nov 2013 23:02:16 GMT
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

On Thu, Oct 31, 2013 at 7:14 PM, John Vines <> wrote:
> On Thu, Oct 31, 2013 at 4:59 PM, Sean Busbey <> wrote:
>> On Thu, Oct 31, 2013 at 3:45 PM, John Vines <> 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.
> 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, are
> all the sub-tasks (though some should also qualify as bugs). For
> convenience, non-sub-tasks are
> . 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]:
>> --
>> Sean

View raw message