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/10/31 18:02:49 UTC
1.6.0 Feature Freeze
I've been going through the tickets (and hopefully not stepping on too many
toes) for scoping things into 1.6 as we approach the deadline. However,
looking through the tickets, there seem to be 4 major tasks that have SOME
amount of work ahead of them to work in a release. To me, these are:
https://issues.apache.org/jira/browse/ACCUMULO-118 - Multiple HDFS spanning
https://issues.apache.org/jira/browse/ACCUMULO-1009 - SSL
https://issues.apache.org/jira/browse/ACCUMULO-1481 - Isolated Root table
(this may be in conjunction with
https://issues.apache.org/jira/browse/ACCUMULO-802, I am uncertain of the
plan of action of 1481)
https://issues.apache.org/jira/browse/ACCUMULO-1000 - Compare and set
Mutations
These are all tickets that have some standing work and I think these, plus
RFile encryption, are the core features for 1.6. I apologize if I
overlooked any other features in 1.6 in that statement. That said, this is
a LOT of work for people to have pushed in 36 hours. And pulling these
features out will A. be a giant PITA and B. Leave us with a very lackluster
release.
So, I am proposing maintaining the feature freeze of Friday at midnight
that we maintained before, EXCEPT for any thing regarding these 4-5
features I've enumerated. I think an additional week should be sufficient
for these features to be in a release worthy state. This also means that
after the general feature freeze date, all non-critical bugs and additional
features will be bumped to 1.6.1/1.7.0). Because it is a one week timespan,
I think we can hold off on creating the branch for 1.6.0-SNAPSHOT, but if
anyone disagrees a second vote can be put in order by someone who feels
that way.
Please vote on providing a delayed feature freeze for ACCUMULO-118,
ACCUMULO-1009, ACCUMULO-1481, ACCUMULO-802, and ACCUMULO-1000 for Nov 8
23:59 PDT for the master branch. Shortly after this time we will branch
1.6.0-SNAPSHOT from master and increment the version in master in lieu of
the original Nov 1 23:59 PDT deadline. For all other features, the original Nov
1 23:59 PDT applies. "Feature Freeze" means only bug fixes and
documentation updates happen after the date, which implies major code additions
and changes are already in place with appropriate tests.
If a commiter thinks a new feature in 1.6.0-SNAPSHOT is not ready for release,
they should bring it up on the dev list. If agreement can not be reached
on the dev list with 72 hours, then the commiter can call for a vote on
reverting the feature from 1.6.0-SNAPSHOT. The vote must pass with majority
approval[1]. If the vote passes, any commiter can revert the feature from
1.6.0-SNAPSHOT.
This vote will remain open for 72 hours and must have consensus approval[2]
to pass. Because of the conflicting time frames with the feature freeze in
~36 hours, the post feature freeze actions of the shall be delayed until
the end of this vote in the event this vote does not pass. This will not
change the rules of that feature freeze.
[1]:http://www.apache.org/foundation/glossary.html#MajorityApproval
[2]:http://www.apache.org/foundation/glossary.html#ConsensusApproval
Re: 1.6.0 Feature Freeze
Posted by Christopher <ct...@apache.org>.
Yes, that's what I'm saying, because:
1 week (max) delay in pushing/merging is probably a better alternative
for features mostly ready and waiting for feedback before a final
yeah/nay, than somebody eagly pushing them to get them in before the
deadline and having to revert them later because they weren't
sufficiently reviewed.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Thu, Oct 31, 2013 at 1:41 PM, Sean Busbey <bu...@cloudera.com> wrote:
> On Thu, Oct 31, 2013 at 12:37 PM, Christopher <ct...@apache.org> wrote:
>
>> I think a week extension would be good for projects that are under
>> review, but I don't think it should be extended for development on
>> those features (except to address issues from the review). This would
>> also encourage people to push something potentially disruptive to
>> ReviewBoard instead of committing at the last minute and having to
>> revert it later. That would allow us to review stuff that has been
>> ready, but not committed because people have been busy finishing other
>> features for the feature freeze and haven't had time to review it yet.
>>
>>
> Just to make sure I'm reading this right:
>
> you're saying we include things that are in review board as of the original
> feature freeze date? And then they get pushed post-feature-freeze date once
> their reviews have iterated to acceptance?
>
>
> --
> 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
>>
Re: 1.6.0 Feature Freeze
Posted by John Vines <vi...@apache.org>.
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 Sean Busbey <bu...@cloudera.com>.
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.
[1]: http://bit.ly/18H9jpx
--
Sean
Re: 1.6.0 Feature Freeze
Posted by John Vines <vi...@apache.org>.
On Thu, Oct 31, 2013 at 4:39 PM, Sean Busbey <bu...@cloudera.com> wrote:
> On Thu, Oct 31, 2013 at 1:35 PM, John Vines <vi...@apache.org> wrote:
>
> > >
> >
> > So I am interpreting it as all code modifications must be into the
> codebase
> > or review board by the freeze date. Which could be beneifical, however-
> > 1. What about the case where a patch needs to be modified? What if it's a
> > really minor change vs. a major change? Where's the line?
> >
>
> That's up to the release manager, though they can ask the community for
> feedback. :)
>
> Generally, I think this is a non-issue. review board lets you post updates
> to your patch. If it didn't, feedback would be useless. I don't think we're
> saying you can't update your review board.
>
> So I think it comes down to the feedback itself. if it suggests a change
> that you can incorporate into the existing patch, good to go. if it's
> requires a rewrite, then it sounds more like a -1 and goes to the
> removal-vote process.
>
>
>
> > 2. In the case of features that have multiple subtasks, they have
> > complementing features that NEED to exist to make the main feature
> > usable/maintainable. What happens if we don't get those in?
> >
>
> That's why we have a call-to-remove part of the vote, right? committer
> votes will determine if a given feature has retained enough to be included.
>
> This is also a big advantage of review-then-commit and iterating within the
> ticket before pushing up. You can have these kind of inclusion
> conversations at a much lower cost when you aren't facing the prospect of
> trudging through a bunch of reverts.
>
> --
> Sean
>
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.
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?
Re: 1.6.0 Feature Freeze
Posted by Sean Busbey <bu...@cloudera.com>.
On Thu, Oct 31, 2013 at 1:35 PM, John Vines <vi...@apache.org> wrote:
> >
>
> So I am interpreting it as all code modifications must be into the codebase
> or review board by the freeze date. Which could be beneifical, however-
> 1. What about the case where a patch needs to be modified? What if it's a
> really minor change vs. a major change? Where's the line?
>
That's up to the release manager, though they can ask the community for
feedback. :)
Generally, I think this is a non-issue. review board lets you post updates
to your patch. If it didn't, feedback would be useless. I don't think we're
saying you can't update your review board.
So I think it comes down to the feedback itself. if it suggests a change
that you can incorporate into the existing patch, good to go. if it's
requires a rewrite, then it sounds more like a -1 and goes to the
removal-vote process.
> 2. In the case of features that have multiple subtasks, they have
> complementing features that NEED to exist to make the main feature
> usable/maintainable. What happens if we don't get those in?
>
That's why we have a call-to-remove part of the vote, right? committer
votes will determine if a given feature has retained enough to be included.
This is also a big advantage of review-then-commit and iterating within the
ticket before pushing up. You can have these kind of inclusion
conversations at a much lower cost when you aren't facing the prospect of
trudging through a bunch of reverts.
--
Sean
Re: 1.6.0 Feature Freeze
Posted by John Vines <vi...@apache.org>.
On Thu, Oct 31, 2013 at 2:26 PM, Sean Busbey <bu...@cloudera.com> wrote:
> On Thu, Oct 31, 2013 at 12:41 PM, Sean Busbey <bu...@cloudera.com> wrote:
>
> > On Thu, Oct 31, 2013 at 12:37 PM, Christopher <ct...@apache.org>
> wrote:
> >
> >> I think a week extension would be good for projects that are under
> >> review, but I don't think it should be extended for development on
> >> those features (except to address issues from the review). This would
> >> also encourage people to push something potentially disruptive to
> >> ReviewBoard instead of committing at the last minute and having to
> >> revert it later. That would allow us to review stuff that has been
> >> ready, but not committed because people have been busy finishing other
> >> features for the feature freeze and haven't had time to review it yet.
> >>
> >>
> > Just to make sure I'm reading this right:
> >
> > you're saying we include things that are in review board as of the
> > original feature freeze date? And then they get pushed
> post-feature-freeze
> > date once their reviews have iterated to acceptance?
> >
> >
> >
>
> If I am interpreting Chris' proposal correctly, I like it better than a
> general one week extension.
>
> In addition to the benefits he lists, I think it also makes us much more
> likely to get 1-commit-per-ticket, which I'm a huge fan of.
>
> --
> Sean
>
So I am interpreting it as all code modifications must be into the codebase
or review board by the freeze date. Which could be beneifical, however-
1. What about the case where a patch needs to be modified? What if it's a
really minor change vs. a major change? Where's the line?
2. In the case of features that have multiple subtasks, they have
complementing features that NEED to exist to make the main feature
usable/maintainable. What happens if we don't get those in?
Re: 1.6.0 Feature Freeze
Posted by Sean Busbey <bu...@cloudera.com>.
On Thu, Oct 31, 2013 at 12:41 PM, Sean Busbey <bu...@cloudera.com> wrote:
> On Thu, Oct 31, 2013 at 12:37 PM, Christopher <ct...@apache.org> wrote:
>
>> I think a week extension would be good for projects that are under
>> review, but I don't think it should be extended for development on
>> those features (except to address issues from the review). This would
>> also encourage people to push something potentially disruptive to
>> ReviewBoard instead of committing at the last minute and having to
>> revert it later. That would allow us to review stuff that has been
>> ready, but not committed because people have been busy finishing other
>> features for the feature freeze and haven't had time to review it yet.
>>
>>
> Just to make sure I'm reading this right:
>
> you're saying we include things that are in review board as of the
> original feature freeze date? And then they get pushed post-feature-freeze
> date once their reviews have iterated to acceptance?
>
>
>
If I am interpreting Chris' proposal correctly, I like it better than a
general one week extension.
In addition to the benefits he lists, I think it also makes us much more
likely to get 1-commit-per-ticket, which I'm a huge fan of.
--
Sean
Re: 1.6.0 Feature Freeze
Posted by Sean Busbey <bu...@cloudera.com>.
On Thu, Oct 31, 2013 at 12:37 PM, Christopher <ct...@apache.org> wrote:
> I think a week extension would be good for projects that are under
> review, but I don't think it should be extended for development on
> those features (except to address issues from the review). This would
> also encourage people to push something potentially disruptive to
> ReviewBoard instead of committing at the last minute and having to
> revert it later. That would allow us to review stuff that has been
> ready, but not committed because people have been busy finishing other
> features for the feature freeze and haven't had time to review it yet.
>
>
Just to make sure I'm reading this right:
you're saying we include things that are in review board as of the original
feature freeze date? And then they get pushed post-feature-freeze date once
their reviews have iterated to acceptance?
--
Sean
Re: 1.6.0 Feature Freeze
Posted by Christopher <ct...@apache.org>.
I think a week extension would be good for projects that are under
review, but I don't think it should be extended for development on
those features (except to address issues from the review). This would
also encourage people to push something potentially disruptive to
ReviewBoard instead of committing at the last minute and having to
revert it later. That would allow us to review stuff that has been
ready, but not committed because people have been busy finishing other
features for the feature freeze and haven't had time to review it yet.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Thu, Oct 31, 2013 at 1:02 PM, John Vines <vi...@apache.org> wrote:
> I've been going through the tickets (and hopefully not stepping on too many
> toes) for scoping things into 1.6 as we approach the deadline. However,
> looking through the tickets, there seem to be 4 major tasks that have SOME
> amount of work ahead of them to work in a release. To me, these are:
>
> https://issues.apache.org/jira/browse/ACCUMULO-118 - Multiple HDFS spanning
> https://issues.apache.org/jira/browse/ACCUMULO-1009 - SSL
> https://issues.apache.org/jira/browse/ACCUMULO-1481 - Isolated Root table
> (this may be in conjunction with
> https://issues.apache.org/jira/browse/ACCUMULO-802, I am uncertain of the
> plan of action of 1481)
> https://issues.apache.org/jira/browse/ACCUMULO-1000 - Compare and set
> Mutations
>
> These are all tickets that have some standing work and I think these, plus
> RFile encryption, are the core features for 1.6. I apologize if I
> overlooked any other features in 1.6 in that statement. That said, this is
> a LOT of work for people to have pushed in 36 hours. And pulling these
> features out will A. be a giant PITA and B. Leave us with a very lackluster
> release.
>
>
> So, I am proposing maintaining the feature freeze of Friday at midnight
> that we maintained before, EXCEPT for any thing regarding these 4-5
> features I've enumerated. I think an additional week should be sufficient
> for these features to be in a release worthy state. This also means that
> after the general feature freeze date, all non-critical bugs and additional
> features will be bumped to 1.6.1/1.7.0). Because it is a one week timespan,
> I think we can hold off on creating the branch for 1.6.0-SNAPSHOT, but if
> anyone disagrees a second vote can be put in order by someone who feels
> that way.
>
>
>
> Please vote on providing a delayed feature freeze for ACCUMULO-118,
> ACCUMULO-1009, ACCUMULO-1481, ACCUMULO-802, and ACCUMULO-1000 for Nov 8
> 23:59 PDT for the master branch. Shortly after this time we will branch
> 1.6.0-SNAPSHOT from master and increment the version in master in lieu of
> the original Nov 1 23:59 PDT deadline. For all other features, the original Nov
> 1 23:59 PDT applies. "Feature Freeze" means only bug fixes and
> documentation updates happen after the date, which implies major code additions
> and changes are already in place with appropriate tests.
>
> If a commiter thinks a new feature in 1.6.0-SNAPSHOT is not ready for release,
> they should bring it up on the dev list. If agreement can not be reached
> on the dev list with 72 hours, then the commiter can call for a vote on
> reverting the feature from 1.6.0-SNAPSHOT. The vote must pass with majority
> approval[1]. If the vote passes, any commiter can revert the feature from
> 1.6.0-SNAPSHOT.
>
> This vote will remain open for 72 hours and must have consensus approval[2]
> to pass. Because of the conflicting time frames with the feature freeze in
> ~36 hours, the post feature freeze actions of the shall be delayed until
> the end of this vote in the event this vote does not pass. This will not
> change the rules of that feature freeze.
>
>
> [1]:http://www.apache.org/foundation/glossary.html#MajorityApproval
> [2]:http://www.apache.org/foundation/glossary.html#ConsensusApproval
Re: 1.6.0 Feature Freeze
Posted by John Vines <vi...@apache.org>.
On Thu, Oct 31, 2013 at 1:39 PM, Sean Busbey <bu...@cloudera.com> wrote:
> On Thu, Oct 31, 2013 at 12:02 PM, John Vines <vi...@apache.org> wrote:
>
>>
>> So, I am proposing maintaining the feature freeze of Friday at midnight
>> that we maintained before, EXCEPT for any thing regarding these 4-5
>> features I've enumerated. I think an additional week should be sufficient
>> for these features to be in a release worthy state. This also means that
>> after the general feature freeze date, all non-critical bugs and
>> additional
>> features will be bumped to 1.6.1/1.7.0). Because it is a one week
>> timespan,
>> I think we can hold off on creating the branch for 1.6.0-SNAPSHOT, but if
>> anyone disagrees a second vote can be put in order by someone who feels
>> that way.
>>
>
> Can we get some idea of scope for "any thing regarding these [...]
> features"?
>
> Could we limit it to tickets that currently exist as subtasks of the list
> of top level features?
>
This was my intent when I said "any thing regarding these [...] features".
I perceive that any additional tickets that should come up from those
features would be bugs or features worth coming in down the road.
>
> Could the people currently assigned to those tickets confirm that a week
> is a realistic goal?
>
Agreed. In addition, if they could scope sub-tasks into must haves vs. nice
to haves for a release, that would be beneficial as well.
>
> --
> Sean
>
Re: 1.6.0 Feature Freeze
Posted by Sean Busbey <bu...@cloudera.com>.
On Thu, Oct 31, 2013 at 12:02 PM, John Vines <vi...@apache.org> wrote:
>
> So, I am proposing maintaining the feature freeze of Friday at midnight
> that we maintained before, EXCEPT for any thing regarding these 4-5
> features I've enumerated. I think an additional week should be sufficient
> for these features to be in a release worthy state. This also means that
> after the general feature freeze date, all non-critical bugs and additional
> features will be bumped to 1.6.1/1.7.0). Because it is a one week timespan,
> I think we can hold off on creating the branch for 1.6.0-SNAPSHOT, but if
> anyone disagrees a second vote can be put in order by someone who feels
> that way.
>
Can we get some idea of scope for "any thing regarding these [...]
features"?
Could we limit it to tickets that currently exist as subtasks of the list
of top level features?
Could the people currently assigned to those tickets confirm that a week is
a realistic goal?
--
Sean
Re: 1.6.0 Feature Freeze
Posted by John Vines <vi...@apache.org>.
On Thu, Oct 31, 2013 at 2:02 PM, Sean Busbey <bu...@cloudera.com> wrote:
> On Thu, Oct 31, 2013 at 12:43 PM, Josh Elser <jo...@gmail.com> wrote:
>
> > I'm fine with the idea of what you're proposing. I'll hold off on an
> > actual vote until the details are resolved (Christopher's and Sean's
> > responses)
> >
> >
> Also, if we re-do calling the vote, I'd ask that we name John Vines the
> release manager[1] for 1.6.0 as a part of it. Our release guide[2] doesn't
> state when we determine the release manager, but I think it makes sense to
> do by the time of declaring a feature freeze (and I'd really prefer we do
> it when road-mapping a major version).
>
Sure, that's fine by me. I don't mind doing this for other releases, but
it's a bit new to me. Next time I won't wait for a week before to start
culling tickets.
>
> Also, one nit: the subject for the vote should include the [VOTE] marker
> for the benefit of less-active list members.
>
Once we get some more responses to Sean's and Chris's comments (like Josh)
I'll issue the ACTUAL vote. I'll try to remember this from here on as well.
>
> [1]: http://www.apache.org/dev/release-publishing.html#release_manager
> [2]: http://accumulo.apache.org/governance/releasing.html
>
>
> --
> Sean
>
Re: 1.6.0 Feature Freeze
Posted by Billie Rinaldi <bi...@gmail.com>.
On Thu, Oct 31, 2013 at 11:02 AM, Sean Busbey <bu...@cloudera.com> wrote:
> On Thu, Oct 31, 2013 at 12:43 PM, Josh Elser <jo...@gmail.com> wrote:
>
> > I'm fine with the idea of what you're proposing. I'll hold off on an
> > actual vote until the details are resolved (Christopher's and Sean's
> > responses)
> >
> >
> Also, if we re-do calling the vote, I'd ask that we name John Vines the
> release manager[1] for 1.6.0 as a part of it. Our release guide[2] doesn't
> state when we determine the release manager, but I think it makes sense to
> do by the time of declaring a feature freeze (and I'd really prefer we do
> it when road-mapping a major version).
>
Our guide doesn't mention a release manager because we haven't explicitly
identified release managers in the past.
Which is not to say that I am against having a release manager.
>
> Also, one nit: the subject for the vote should include the [VOTE] marker
> for the benefit of less-active list members.
>
> [1]: http://www.apache.org/dev/release-publishing.html#release_manager
> [2]: http://accumulo.apache.org/governance/releasing.html
>
>
> --
> Sean
>
Re: 1.6.0 Feature Freeze
Posted by Sean Busbey <bu...@cloudera.com>.
On Thu, Oct 31, 2013 at 12:43 PM, Josh Elser <jo...@gmail.com> wrote:
> I'm fine with the idea of what you're proposing. I'll hold off on an
> actual vote until the details are resolved (Christopher's and Sean's
> responses)
>
>
Also, if we re-do calling the vote, I'd ask that we name John Vines the
release manager[1] for 1.6.0 as a part of it. Our release guide[2] doesn't
state when we determine the release manager, but I think it makes sense to
do by the time of declaring a feature freeze (and I'd really prefer we do
it when road-mapping a major version).
Also, one nit: the subject for the vote should include the [VOTE] marker
for the benefit of less-active list members.
[1]: http://www.apache.org/dev/release-publishing.html#release_manager
[2]: http://accumulo.apache.org/governance/releasing.html
--
Sean
Re: 1.6.0 Feature Freeze
Posted by Josh Elser <jo...@gmail.com>.
I'm fine with the idea of what you're proposing. I'll hold off on an
actual vote until the details are resolved (Christopher's and Sean's
responses)
On 10/31/13, 1:02 PM, John Vines wrote:
> I've been going through the tickets (and hopefully not stepping on too many
> toes) for scoping things into 1.6 as we approach the deadline. However,
> looking through the tickets, there seem to be 4 major tasks that have SOME
> amount of work ahead of them to work in a release. To me, these are:
>
> https://issues.apache.org/jira/browse/ACCUMULO-118 - Multiple HDFS spanning
> https://issues.apache.org/jira/browse/ACCUMULO-1009 - SSL
> https://issues.apache.org/jira/browse/ACCUMULO-1481 - Isolated Root table
> (this may be in conjunction with
> https://issues.apache.org/jira/browse/ACCUMULO-802, I am uncertain of the
> plan of action of 1481)
> https://issues.apache.org/jira/browse/ACCUMULO-1000 - Compare and set
> Mutations
>
> These are all tickets that have some standing work and I think these, plus
> RFile encryption, are the core features for 1.6. I apologize if I
> overlooked any other features in 1.6 in that statement. That said, this is
> a LOT of work for people to have pushed in 36 hours. And pulling these
> features out will A. be a giant PITA and B. Leave us with a very lackluster
> release.
>
>
> So, I am proposing maintaining the feature freeze of Friday at midnight
> that we maintained before, EXCEPT for any thing regarding these 4-5
> features I've enumerated. I think an additional week should be sufficient
> for these features to be in a release worthy state. This also means that
> after the general feature freeze date, all non-critical bugs and additional
> features will be bumped to 1.6.1/1.7.0). Because it is a one week timespan,
> I think we can hold off on creating the branch for 1.6.0-SNAPSHOT, but if
> anyone disagrees a second vote can be put in order by someone who feels
> that way.
>
>
>
> Please vote on providing a delayed feature freeze for ACCUMULO-118,
> ACCUMULO-1009, ACCUMULO-1481, ACCUMULO-802, and ACCUMULO-1000 for Nov 8
> 23:59 PDT for the master branch. Shortly after this time we will branch
> 1.6.0-SNAPSHOT from master and increment the version in master in lieu of
> the original Nov 1 23:59 PDT deadline. For all other features, the original Nov
> 1 23:59 PDT applies. "Feature Freeze" means only bug fixes and
> documentation updates happen after the date, which implies major code additions
> and changes are already in place with appropriate tests.
>
> If a commiter thinks a new feature in 1.6.0-SNAPSHOT is not ready for release,
> they should bring it up on the dev list. If agreement can not be reached
> on the dev list with 72 hours, then the commiter can call for a vote on
> reverting the feature from 1.6.0-SNAPSHOT. The vote must pass with majority
> approval[1]. If the vote passes, any commiter can revert the feature from
> 1.6.0-SNAPSHOT.
>
> This vote will remain open for 72 hours and must have consensus approval[2]
> to pass. Because of the conflicting time frames with the feature freeze in
> ~36 hours, the post feature freeze actions of the shall be delayed until
> the end of this vote in the event this vote does not pass. This will not
> change the rules of that feature freeze.
>
>
> [1]:http://www.apache.org/foundation/glossary.html#MajorityApproval
> [2]:http://www.apache.org/foundation/glossary.html#ConsensusApproval
>