You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@accumulo.apache.org by John Vines <vi...@apache.org> on 2013/11/01 00:14:17 UTC
Re: 1.6.0 Feature Freeze
On Thu, Oct 31, 2013 at 4:59 PM, Sean Busbey <bu...@cloudera.com> wrote:
> On Thu, Oct 31, 2013 at 3:45 PM, John Vines <vi...@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
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
>
Re: 1.6.0 Feature Freeze
Posted by Christopher <ct...@apache.org>.
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 <vi...@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 <jo...@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 <vi...@apache.org> wrote:
>>>
>>>> On Thu, Oct 31, 2013 at 4:59 PM, Sean Busbey <bu...@cloudera.com>
>>>> wrote:
>>>>
>>>> On Thu, Oct 31, 2013 at 3:45 PM, John Vines <vi...@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
>>>>>
>>>>>
Re: 1.6.0 Feature Freeze
Posted by John Vines <vi...@apache.org>.
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 <jo...@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 <vi...@apache.org> wrote:
>>
>>> On Thu, Oct 31, 2013 at 4:59 PM, Sean Busbey <bu...@cloudera.com>
>>> wrote:
>>>
>>> On Thu, Oct 31, 2013 at 3:45 PM, John Vines <vi...@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
>>>>
>>>>
Re: 1.6.0 Feature Freeze
Posted by Josh Elser <jo...@gmail.com>.
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 <vi...@apache.org> wrote:
>> On Thu, Oct 31, 2013 at 4:59 PM, Sean Busbey <bu...@cloudera.com> wrote:
>>
>>> On Thu, Oct 31, 2013 at 3:45 PM, John Vines <vi...@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
>> 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
>>>
Re: 1.6.0 Feature Freeze
Posted by Christopher <ct...@apache.org>.
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 <vi...@apache.org> wrote:
> On Thu, Oct 31, 2013 at 4:59 PM, Sean Busbey <bu...@cloudera.com> wrote:
>
>> On Thu, Oct 31, 2013 at 3:45 PM, John Vines <vi...@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
> 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
>>