You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@accumulo.apache.org by Sean Busbey <bu...@cloudera.com> on 2014/03/11 21:20:40 UTC
[DISCUSS] Accumulo Bylaw fixes
Moving this over to its own DISCUSS thread so we can keep the VOTE easier
to follow.
wrt #4, I'm with Mike on this. One of our big problems, as a community, is
lack of steady release cadence. Even once we decide on a feature freeze, we
don't have enough rigor in driving to release. For example, 1.6.0 hit
feature freeze 4.5 months ago[1]. I think John is doing fine given the
circumstances, but without a date to drive towards it's hard to justify
throwing stuff off the raft.
Since we'll presumably be updating the bylaws for the next vote, I'd like
to see a definition for the Release Manager role since we reference it.
[1]: http://s.apache.org/accumulo_1.6.0_feature_freeze_vote
-Sean
On Tue, Mar 11, 2014 at 1:17 PM, Mike Drob <ma...@cloudera.com> wrote:
> 1) Agree w/ Bill.
>
> 2) Agree w/ Bill.
>
> 3) In my understanding, codebase includes the site svn, the primary git
> repository, and all contrib repositories. Adoption of a new codebase
> generally refers to the creation of a new contrib repository. However, I
> could see it also expanded to cover things like re-doing the entire site
> look and feel, or merging a contrib project into the primary codebase.
> Christopher, do you have any proposed verbiage that you would like to see
> specifically?
>
> 4) I very much disagree, Christopher. Having a dedicated release manager is
> critical to having a release occur in a timely manner. Further, the
> community needs to be able to make hard decisions, like setting a feature
> or code freeze date, or pulling incomplete work out of a branch. Right now,
> we have release managers in name only, and I would love to see us give them
> more authority on performing the release - right now we have a steady
> stream of small changes that developers feel should be exempt from the
> freeze, something I'm guilty of myself as well. I see the lack of a
> formalized release plan as one reason for why releases tend to drag on for
> far too long.
>
> In short, if we don't have a release manager pushing for them, then
> releases just won't happen. It's a gruelling task, and we need to have
> procedure to bless somebody to do it.
>
>
> Mike
>
>
> On Mon, Mar 10, 2014 at 11:03 PM, Bill Havanki <bhavanki@clouderagovt.com
> >wrote:
>
> > My sense from the conversations leading up to the vote:
> >
> > 1) I believe the list is comprehensive, in that no other voting actions
> are
> > contemplated. If we realize we need a new one, we can add it later.
> >
> > 2) We determined that a committer, by ASF rules, cannot truly lose
> > committer status [1], so no removal procedure is defined. Removal of a
> PMC
> > member is up to the ASF Board [2], so no procedure is defined.
> >
> > 3) I see no harm in adding a definition.
> >
> > 4) I think the "release plan" is the process for cutting a release, while
> > "product release" is for approving a specific RC as the release. For me,
> a
> > boilerplate release plan with customizations (who is the RM, what tests
> are
> > needed, time frame for freezes, etc.) would be nice to have laid out.
> >
> > [1] http://www.apache.org/dev/committers.html#committer-set-term
> > [2] http://www.apache.org/dev/pmc.html#pmc-removal
> >
> >
> > On Mon, Mar 10, 2014 at 5:52 PM, Christopher <ct...@apache.org>
> wrote:
> >
> > > Since I didn't technically vote, I guess I will now:
> > > I'm going to give it a -1, pending the resolution the following
> > > issues, and for an opportunity to correct the minor punctuation/typos.
> > >
> > > Specifically, I'd like these addressed before I change my vote:
> > > 1) clarification of whether the ACTIONS list is comprehensive
> > > 2) clarify reinstatement in the absence of a lack of removal procedures
> > > 3) codebase defined (or at least, Adoption of New Codebase clarified)
> > > 4) remove "release plan" as requiring a vote (or discuss), because
> > > while it is nice to coordinate release candidates through a release
> > > manager, I'm not sure it should be strictly necessary that release
> > > candidates be planned, or limited to that release manager.
> > >
> > >
> > > --
> > > Christopher L Tubbs II
> > > http://gravatar.com/ctubbsii
> > >
> > >
> > > On Mon, Mar 10, 2014 at 5:08 PM, Christopher <ct...@apache.org>
> > wrote:
> > > > ***Punctuation:
> > > >
> > > > PMC section:
> > > > "PMC from a Foundation perspective is" -> "PMC, from a Foundation
> > > > perspective, is"
> > > > "Secondly " -> "Secondly, "
> > > > "long term" -> "long-term"
> > > > "not coding - but to ensure" -> "not coding, but to ensure"
> > > > "Within the ASF we worry" -> "Within the ASF, we worry"
> > > >
> > > > VETOES section (comma):
> > > > "veto - merely that" -> "veto, merely that"
> > > >
> > > > ***Typos:
> > > >
> > > > APPROVALS section (typo):
> > > > "that -1 votes" -> "than -1 votes"
> > > >
> > > > ***Definitions:
> > > > I would like to see "codebase" defined. It's used throughout, but is
> > > > never clearly defined... particularly in the "Adoption of New
> > > > Codebase" section of the ACTIONS section.
> > > >
> > > > ***Other:
> > > > In the ACTIONS section, it describes reinstatement actions, but not
> > > > removal actions, so it's not clear what reinstatement means.
> > > >
> > > > It should also be made clear that the ACTIONS section is not a
> > > > comprehensive list of actions.
> > > >
> > > > I'm also not sure that the "Release plan" should require a vote, as
> > > > this seems covered by the "Product release" situation. The other
> > > > actions seem to imply a vote is required for that action. Are we
> > > > saying that planning to release requires a vote? If so, I can get on
> > > > board... I just don't remember that happening in the past, so this
> > > > isn't so much a formalization of our existing practices, but also
> > > > establishing a new one as well. And, in this case, I'm not sure it's
> > > > one we need.
> > > >
> > > > --
> > > > Christopher L Tubbs II
> > > > http://gravatar.com/ctubbsii
> > > >
>
Re: [DISCUSS] Accumulo Bylaw fixes
Posted by Sean Busbey <bu...@cloudera.com>.
I do like the idea of a development schedule. I think for major releases we
should setting target dates when we start, which will practically require a
development schedule of some kind.
I still think a Release Manager is needed for this, because it's
impractical to do a PMC vote every time we need to make a decision about if
e.g. a bug fix is critical enough to include or if a feature is complete
enough to pass the gate for a given release.
On Thu, Mar 13, 2014 at 11:44 AM, Christopher <ct...@apache.org> wrote:
> One thing we could do that might help releases is to isolate
> new/improved feature work to branches only, before merging to master,
> and establish a development schedule, not just a release schedule.
>
> We can put bug fixes in master, but new features really shouldn't be
> put in master until they are ready for inclusion in a release. This
> makes it easier to roll back incomplete features, but makes it harder
> to review/test multiple branches to determine if it's ready for
> inclusion in a release.
>
> This model would probably require more people to be proactive about
> evaluating the state of multiple feature branches, so follow-on
> quality/usability/implementation improvements can be made before
> merging to master.
>
> One thing that might help is to establish a development schedule. At
> 30% through the dev schedule, features could be assessed (by self-eval
> and soliciting feedback) for additional improvements/changes. If they
> aren't ready for assessment, then they get punted to the next version.
> Whatever comes out of the assessment can be worked until 60% of the
> dev schedule, at which point we determine whether they are ready for
> inclusion in a release. If not, they are punted to the next version.
> However, if they are ready, then the remaining 40% would be
> integration to the master branch, testing and bug fixes. Any suggested
> non-bugfix improvements found after the choice to include would have
> to go in the next version.
>
> Formally, the 60% mark would be feature freeze. These numbers are also
> just rough guesses for what might work, and this is just an unpolished
> idea, though. This might only be applicable to major features, but if
> we operate this way for all new features/improvements, it could also
> help avoid the situation where we didn't realize that a minor feature
> would be turn into a major one.
>
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Thu, Mar 13, 2014 at 12:21 PM, Keith Turner <ke...@deenlo.com> wrote:
> > On Tue, Mar 11, 2014 at 4:20 PM, Sean Busbey <busbey+lists@cloudera.com
> >wrote:
> >
> >> Moving this over to its own DISCUSS thread so we can keep the VOTE
> easier
> >> to follow.
> >>
> >> wrt #4, I'm with Mike on this. One of our big problems, as a community,
> is
> >> lack of steady release cadence. Even once we decide on a feature
> freeze, we
> >> don't have enough rigor in driving to release. For example, 1.6.0 hit
> >> feature freeze 4.5 months ago[1]. I think John is doing fine given the
> >> circumstances, but without a date to drive towards it's hard to justify
> >> throwing stuff off the raft.
> >>
> >> Since we'll presumably be updating the bylaws for the next vote, I'd
> like
> >> to see a definition for the Release Manager role since we reference it.
> >>
> >
> > I have been reading through a lot of the comments made so far.
> >
> > A release manger is a possible solution to the problem of releases
> > languish. I think it would be help to list what are causing releases to
> > languish..
> >
> > 1. Incomplete features checked in before feature freeze
> > 2. A steady of stream of non-essential changes after feature freeze
> > 3. Testing takes a while and has to be redone after major changes are
> made
> > 4. Critical bugs found during test need to be fixed
> >
> > What else other things are slowing down releases?
> >
> > I am not convinced a release manager can solve these problems, my main
> > concern is scalability. The 1.7.0 release manager would have to really
> be
> > on top of all of the 1.7.0 commits, even before feature freeze. If the
> > release manager does not deal w/ incomplete features early, it will be
> much
> > harder to deal with them later. W/ CTR commits can come in faster than
> the
> > release manager can process them. This make me think of the benevelont
> > dictator model where only the 1.7.0 RM merges things into 1.7.0-SNAPSHOT.
> > They can do this as they have time. I have been looking at Gerrit a bit
> > lately. I have never used it, but I like what I have read. It seems
> like
> > gerrit is better than RB because its more automated w/ less friction.
> > Using Gerrit and RTC would be more scalable than a single RM.
> >
> >
> >> [1]: http://s.apache.org/accumulo_1.6.0_feature_freeze_vote
> >>
> >> -Sean
> >>
> >> On Tue, Mar 11, 2014 at 1:17 PM, Mike Drob <ma...@cloudera.com> wrote:
> >>
> >> > 1) Agree w/ Bill.
> >> >
> >> > 2) Agree w/ Bill.
> >> >
> >> > 3) In my understanding, codebase includes the site svn, the primary
> git
> >> > repository, and all contrib repositories. Adoption of a new codebase
> >> > generally refers to the creation of a new contrib repository.
> However, I
> >> > could see it also expanded to cover things like re-doing the entire
> site
> >> > look and feel, or merging a contrib project into the primary codebase.
> >> > Christopher, do you have any proposed verbiage that you would like to
> see
> >> > specifically?
> >> >
> >> > 4) I very much disagree, Christopher. Having a dedicated release
> manager
> >> is
> >> > critical to having a release occur in a timely manner. Further, the
> >> > community needs to be able to make hard decisions, like setting a
> feature
> >> > or code freeze date, or pulling incomplete work out of a branch. Right
> >> now,
> >> > we have release managers in name only, and I would love to see us give
> >> them
> >> > more authority on performing the release - right now we have a steady
> >> > stream of small changes that developers feel should be exempt from the
> >> > freeze, something I'm guilty of myself as well. I see the lack of a
> >> > formalized release plan as one reason for why releases tend to drag on
> >> for
> >> > far too long.
> >> >
> >> > In short, if we don't have a release manager pushing for them, then
> >> > releases just won't happen. It's a gruelling task, and we need to have
> >> > procedure to bless somebody to do it.
> >> >
> >> >
> >> > Mike
> >> >
> >> >
> >> > On Mon, Mar 10, 2014 at 11:03 PM, Bill Havanki <
> >> bhavanki@clouderagovt.com
> >> > >wrote:
> >> >
> >> > > My sense from the conversations leading up to the vote:
> >> > >
> >> > > 1) I believe the list is comprehensive, in that no other voting
> actions
> >> > are
> >> > > contemplated. If we realize we need a new one, we can add it later.
> >> > >
> >> > > 2) We determined that a committer, by ASF rules, cannot truly lose
> >> > > committer status [1], so no removal procedure is defined. Removal
> of a
> >> > PMC
> >> > > member is up to the ASF Board [2], so no procedure is defined.
> >> > >
> >> > > 3) I see no harm in adding a definition.
> >> > >
> >> > > 4) I think the "release plan" is the process for cutting a release,
> >> while
> >> > > "product release" is for approving a specific RC as the release. For
> >> me,
> >> > a
> >> > > boilerplate release plan with customizations (who is the RM, what
> tests
> >> > are
> >> > > needed, time frame for freezes, etc.) would be nice to have laid
> out.
> >> > >
> >> > > [1] http://www.apache.org/dev/committers.html#committer-set-term
> >> > > [2] http://www.apache.org/dev/pmc.html#pmc-removal
> >> > >
> >> > >
> >> > > On Mon, Mar 10, 2014 at 5:52 PM, Christopher <ct...@apache.org>
> >> > wrote:
> >> > >
> >> > > > Since I didn't technically vote, I guess I will now:
> >> > > > I'm going to give it a -1, pending the resolution the following
> >> > > > issues, and for an opportunity to correct the minor
> >> punctuation/typos.
> >> > > >
> >> > > > Specifically, I'd like these addressed before I change my vote:
> >> > > > 1) clarification of whether the ACTIONS list is comprehensive
> >> > > > 2) clarify reinstatement in the absence of a lack of removal
> >> procedures
> >> > > > 3) codebase defined (or at least, Adoption of New Codebase
> clarified)
> >> > > > 4) remove "release plan" as requiring a vote (or discuss), because
> >> > > > while it is nice to coordinate release candidates through a
> release
> >> > > > manager, I'm not sure it should be strictly necessary that release
> >> > > > candidates be planned, or limited to that release manager.
> >> > > >
> >> > > >
> >> > > > --
> >> > > > Christopher L Tubbs II
> >> > > > http://gravatar.com/ctubbsii
> >> > > >
> >> > > >
> >> > > > On Mon, Mar 10, 2014 at 5:08 PM, Christopher <ctubbsii@apache.org
> >
> >> > > wrote:
> >> > > > > ***Punctuation:
> >> > > > >
> >> > > > > PMC section:
> >> > > > > "PMC from a Foundation perspective is" -> "PMC, from a
> Foundation
> >> > > > > perspective, is"
> >> > > > > "Secondly " -> "Secondly, "
> >> > > > > "long term" -> "long-term"
> >> > > > > "not coding - but to ensure" -> "not coding, but to ensure"
> >> > > > > "Within the ASF we worry" -> "Within the ASF, we worry"
> >> > > > >
> >> > > > > VETOES section (comma):
> >> > > > > "veto - merely that" -> "veto, merely that"
> >> > > > >
> >> > > > > ***Typos:
> >> > > > >
> >> > > > > APPROVALS section (typo):
> >> > > > > "that -1 votes" -> "than -1 votes"
> >> > > > >
> >> > > > > ***Definitions:
> >> > > > > I would like to see "codebase" defined. It's used throughout,
> but
> >> is
> >> > > > > never clearly defined... particularly in the "Adoption of New
> >> > > > > Codebase" section of the ACTIONS section.
> >> > > > >
> >> > > > > ***Other:
> >> > > > > In the ACTIONS section, it describes reinstatement actions, but
> not
> >> > > > > removal actions, so it's not clear what reinstatement means.
> >> > > > >
> >> > > > > It should also be made clear that the ACTIONS section is not a
> >> > > > > comprehensive list of actions.
> >> > > > >
> >> > > > > I'm also not sure that the "Release plan" should require a
> vote, as
> >> > > > > this seems covered by the "Product release" situation. The other
> >> > > > > actions seem to imply a vote is required for that action. Are we
> >> > > > > saying that planning to release requires a vote? If so, I can
> get
> >> on
> >> > > > > board... I just don't remember that happening in the past, so
> this
> >> > > > > isn't so much a formalization of our existing practices, but
> also
> >> > > > > establishing a new one as well. And, in this case, I'm not sure
> >> it's
> >> > > > > one we need.
> >> > > > >
> >> > > > > --
> >> > > > > Christopher L Tubbs II
> >> > > > > http://gravatar.com/ctubbsii
> >> > > > >
> >> >
> >>
>
Re: [DISCUSS] Accumulo Bylaw fixes
Posted by Christopher <ct...@apache.org>.
One thing we could do that might help releases is to isolate
new/improved feature work to branches only, before merging to master,
and establish a development schedule, not just a release schedule.
We can put bug fixes in master, but new features really shouldn't be
put in master until they are ready for inclusion in a release. This
makes it easier to roll back incomplete features, but makes it harder
to review/test multiple branches to determine if it's ready for
inclusion in a release.
This model would probably require more people to be proactive about
evaluating the state of multiple feature branches, so follow-on
quality/usability/implementation improvements can be made before
merging to master.
One thing that might help is to establish a development schedule. At
30% through the dev schedule, features could be assessed (by self-eval
and soliciting feedback) for additional improvements/changes. If they
aren't ready for assessment, then they get punted to the next version.
Whatever comes out of the assessment can be worked until 60% of the
dev schedule, at which point we determine whether they are ready for
inclusion in a release. If not, they are punted to the next version.
However, if they are ready, then the remaining 40% would be
integration to the master branch, testing and bug fixes. Any suggested
non-bugfix improvements found after the choice to include would have
to go in the next version.
Formally, the 60% mark would be feature freeze. These numbers are also
just rough guesses for what might work, and this is just an unpolished
idea, though. This might only be applicable to major features, but if
we operate this way for all new features/improvements, it could also
help avoid the situation where we didn't realize that a minor feature
would be turn into a major one.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Thu, Mar 13, 2014 at 12:21 PM, Keith Turner <ke...@deenlo.com> wrote:
> On Tue, Mar 11, 2014 at 4:20 PM, Sean Busbey <bu...@cloudera.com>wrote:
>
>> Moving this over to its own DISCUSS thread so we can keep the VOTE easier
>> to follow.
>>
>> wrt #4, I'm with Mike on this. One of our big problems, as a community, is
>> lack of steady release cadence. Even once we decide on a feature freeze, we
>> don't have enough rigor in driving to release. For example, 1.6.0 hit
>> feature freeze 4.5 months ago[1]. I think John is doing fine given the
>> circumstances, but without a date to drive towards it's hard to justify
>> throwing stuff off the raft.
>>
>> Since we'll presumably be updating the bylaws for the next vote, I'd like
>> to see a definition for the Release Manager role since we reference it.
>>
>
> I have been reading through a lot of the comments made so far.
>
> A release manger is a possible solution to the problem of releases
> languish. I think it would be help to list what are causing releases to
> languish..
>
> 1. Incomplete features checked in before feature freeze
> 2. A steady of stream of non-essential changes after feature freeze
> 3. Testing takes a while and has to be redone after major changes are made
> 4. Critical bugs found during test need to be fixed
>
> What else other things are slowing down releases?
>
> I am not convinced a release manager can solve these problems, my main
> concern is scalability. The 1.7.0 release manager would have to really be
> on top of all of the 1.7.0 commits, even before feature freeze. If the
> release manager does not deal w/ incomplete features early, it will be much
> harder to deal with them later. W/ CTR commits can come in faster than the
> release manager can process them. This make me think of the benevelont
> dictator model where only the 1.7.0 RM merges things into 1.7.0-SNAPSHOT.
> They can do this as they have time. I have been looking at Gerrit a bit
> lately. I have never used it, but I like what I have read. It seems like
> gerrit is better than RB because its more automated w/ less friction.
> Using Gerrit and RTC would be more scalable than a single RM.
>
>
>> [1]: http://s.apache.org/accumulo_1.6.0_feature_freeze_vote
>>
>> -Sean
>>
>> On Tue, Mar 11, 2014 at 1:17 PM, Mike Drob <ma...@cloudera.com> wrote:
>>
>> > 1) Agree w/ Bill.
>> >
>> > 2) Agree w/ Bill.
>> >
>> > 3) In my understanding, codebase includes the site svn, the primary git
>> > repository, and all contrib repositories. Adoption of a new codebase
>> > generally refers to the creation of a new contrib repository. However, I
>> > could see it also expanded to cover things like re-doing the entire site
>> > look and feel, or merging a contrib project into the primary codebase.
>> > Christopher, do you have any proposed verbiage that you would like to see
>> > specifically?
>> >
>> > 4) I very much disagree, Christopher. Having a dedicated release manager
>> is
>> > critical to having a release occur in a timely manner. Further, the
>> > community needs to be able to make hard decisions, like setting a feature
>> > or code freeze date, or pulling incomplete work out of a branch. Right
>> now,
>> > we have release managers in name only, and I would love to see us give
>> them
>> > more authority on performing the release - right now we have a steady
>> > stream of small changes that developers feel should be exempt from the
>> > freeze, something I'm guilty of myself as well. I see the lack of a
>> > formalized release plan as one reason for why releases tend to drag on
>> for
>> > far too long.
>> >
>> > In short, if we don't have a release manager pushing for them, then
>> > releases just won't happen. It's a gruelling task, and we need to have
>> > procedure to bless somebody to do it.
>> >
>> >
>> > Mike
>> >
>> >
>> > On Mon, Mar 10, 2014 at 11:03 PM, Bill Havanki <
>> bhavanki@clouderagovt.com
>> > >wrote:
>> >
>> > > My sense from the conversations leading up to the vote:
>> > >
>> > > 1) I believe the list is comprehensive, in that no other voting actions
>> > are
>> > > contemplated. If we realize we need a new one, we can add it later.
>> > >
>> > > 2) We determined that a committer, by ASF rules, cannot truly lose
>> > > committer status [1], so no removal procedure is defined. Removal of a
>> > PMC
>> > > member is up to the ASF Board [2], so no procedure is defined.
>> > >
>> > > 3) I see no harm in adding a definition.
>> > >
>> > > 4) I think the "release plan" is the process for cutting a release,
>> while
>> > > "product release" is for approving a specific RC as the release. For
>> me,
>> > a
>> > > boilerplate release plan with customizations (who is the RM, what tests
>> > are
>> > > needed, time frame for freezes, etc.) would be nice to have laid out.
>> > >
>> > > [1] http://www.apache.org/dev/committers.html#committer-set-term
>> > > [2] http://www.apache.org/dev/pmc.html#pmc-removal
>> > >
>> > >
>> > > On Mon, Mar 10, 2014 at 5:52 PM, Christopher <ct...@apache.org>
>> > wrote:
>> > >
>> > > > Since I didn't technically vote, I guess I will now:
>> > > > I'm going to give it a -1, pending the resolution the following
>> > > > issues, and for an opportunity to correct the minor
>> punctuation/typos.
>> > > >
>> > > > Specifically, I'd like these addressed before I change my vote:
>> > > > 1) clarification of whether the ACTIONS list is comprehensive
>> > > > 2) clarify reinstatement in the absence of a lack of removal
>> procedures
>> > > > 3) codebase defined (or at least, Adoption of New Codebase clarified)
>> > > > 4) remove "release plan" as requiring a vote (or discuss), because
>> > > > while it is nice to coordinate release candidates through a release
>> > > > manager, I'm not sure it should be strictly necessary that release
>> > > > candidates be planned, or limited to that release manager.
>> > > >
>> > > >
>> > > > --
>> > > > Christopher L Tubbs II
>> > > > http://gravatar.com/ctubbsii
>> > > >
>> > > >
>> > > > On Mon, Mar 10, 2014 at 5:08 PM, Christopher <ct...@apache.org>
>> > > wrote:
>> > > > > ***Punctuation:
>> > > > >
>> > > > > PMC section:
>> > > > > "PMC from a Foundation perspective is" -> "PMC, from a Foundation
>> > > > > perspective, is"
>> > > > > "Secondly " -> "Secondly, "
>> > > > > "long term" -> "long-term"
>> > > > > "not coding - but to ensure" -> "not coding, but to ensure"
>> > > > > "Within the ASF we worry" -> "Within the ASF, we worry"
>> > > > >
>> > > > > VETOES section (comma):
>> > > > > "veto - merely that" -> "veto, merely that"
>> > > > >
>> > > > > ***Typos:
>> > > > >
>> > > > > APPROVALS section (typo):
>> > > > > "that -1 votes" -> "than -1 votes"
>> > > > >
>> > > > > ***Definitions:
>> > > > > I would like to see "codebase" defined. It's used throughout, but
>> is
>> > > > > never clearly defined... particularly in the "Adoption of New
>> > > > > Codebase" section of the ACTIONS section.
>> > > > >
>> > > > > ***Other:
>> > > > > In the ACTIONS section, it describes reinstatement actions, but not
>> > > > > removal actions, so it's not clear what reinstatement means.
>> > > > >
>> > > > > It should also be made clear that the ACTIONS section is not a
>> > > > > comprehensive list of actions.
>> > > > >
>> > > > > I'm also not sure that the "Release plan" should require a vote, as
>> > > > > this seems covered by the "Product release" situation. The other
>> > > > > actions seem to imply a vote is required for that action. Are we
>> > > > > saying that planning to release requires a vote? If so, I can get
>> on
>> > > > > board... I just don't remember that happening in the past, so this
>> > > > > isn't so much a formalization of our existing practices, but also
>> > > > > establishing a new one as well. And, in this case, I'm not sure
>> it's
>> > > > > one we need.
>> > > > >
>> > > > > --
>> > > > > Christopher L Tubbs II
>> > > > > http://gravatar.com/ctubbsii
>> > > > >
>> >
>>
Re: [DISCUSS] Accumulo Bylaw fixes
Posted by Keith Turner <ke...@deenlo.com>.
On Tue, Mar 11, 2014 at 4:20 PM, Sean Busbey <bu...@cloudera.com>wrote:
> Moving this over to its own DISCUSS thread so we can keep the VOTE easier
> to follow.
>
> wrt #4, I'm with Mike on this. One of our big problems, as a community, is
> lack of steady release cadence. Even once we decide on a feature freeze, we
> don't have enough rigor in driving to release. For example, 1.6.0 hit
> feature freeze 4.5 months ago[1]. I think John is doing fine given the
> circumstances, but without a date to drive towards it's hard to justify
> throwing stuff off the raft.
>
> Since we'll presumably be updating the bylaws for the next vote, I'd like
> to see a definition for the Release Manager role since we reference it.
>
I have been reading through a lot of the comments made so far.
A release manger is a possible solution to the problem of releases
languish. I think it would be help to list what are causing releases to
languish..
1. Incomplete features checked in before feature freeze
2. A steady of stream of non-essential changes after feature freeze
3. Testing takes a while and has to be redone after major changes are made
4. Critical bugs found during test need to be fixed
What else other things are slowing down releases?
I am not convinced a release manager can solve these problems, my main
concern is scalability. The 1.7.0 release manager would have to really be
on top of all of the 1.7.0 commits, even before feature freeze. If the
release manager does not deal w/ incomplete features early, it will be much
harder to deal with them later. W/ CTR commits can come in faster than the
release manager can process them. This make me think of the benevelont
dictator model where only the 1.7.0 RM merges things into 1.7.0-SNAPSHOT.
They can do this as they have time. I have been looking at Gerrit a bit
lately. I have never used it, but I like what I have read. It seems like
gerrit is better than RB because its more automated w/ less friction.
Using Gerrit and RTC would be more scalable than a single RM.
> [1]: http://s.apache.org/accumulo_1.6.0_feature_freeze_vote
>
> -Sean
>
> On Tue, Mar 11, 2014 at 1:17 PM, Mike Drob <ma...@cloudera.com> wrote:
>
> > 1) Agree w/ Bill.
> >
> > 2) Agree w/ Bill.
> >
> > 3) In my understanding, codebase includes the site svn, the primary git
> > repository, and all contrib repositories. Adoption of a new codebase
> > generally refers to the creation of a new contrib repository. However, I
> > could see it also expanded to cover things like re-doing the entire site
> > look and feel, or merging a contrib project into the primary codebase.
> > Christopher, do you have any proposed verbiage that you would like to see
> > specifically?
> >
> > 4) I very much disagree, Christopher. Having a dedicated release manager
> is
> > critical to having a release occur in a timely manner. Further, the
> > community needs to be able to make hard decisions, like setting a feature
> > or code freeze date, or pulling incomplete work out of a branch. Right
> now,
> > we have release managers in name only, and I would love to see us give
> them
> > more authority on performing the release - right now we have a steady
> > stream of small changes that developers feel should be exempt from the
> > freeze, something I'm guilty of myself as well. I see the lack of a
> > formalized release plan as one reason for why releases tend to drag on
> for
> > far too long.
> >
> > In short, if we don't have a release manager pushing for them, then
> > releases just won't happen. It's a gruelling task, and we need to have
> > procedure to bless somebody to do it.
> >
> >
> > Mike
> >
> >
> > On Mon, Mar 10, 2014 at 11:03 PM, Bill Havanki <
> bhavanki@clouderagovt.com
> > >wrote:
> >
> > > My sense from the conversations leading up to the vote:
> > >
> > > 1) I believe the list is comprehensive, in that no other voting actions
> > are
> > > contemplated. If we realize we need a new one, we can add it later.
> > >
> > > 2) We determined that a committer, by ASF rules, cannot truly lose
> > > committer status [1], so no removal procedure is defined. Removal of a
> > PMC
> > > member is up to the ASF Board [2], so no procedure is defined.
> > >
> > > 3) I see no harm in adding a definition.
> > >
> > > 4) I think the "release plan" is the process for cutting a release,
> while
> > > "product release" is for approving a specific RC as the release. For
> me,
> > a
> > > boilerplate release plan with customizations (who is the RM, what tests
> > are
> > > needed, time frame for freezes, etc.) would be nice to have laid out.
> > >
> > > [1] http://www.apache.org/dev/committers.html#committer-set-term
> > > [2] http://www.apache.org/dev/pmc.html#pmc-removal
> > >
> > >
> > > On Mon, Mar 10, 2014 at 5:52 PM, Christopher <ct...@apache.org>
> > wrote:
> > >
> > > > Since I didn't technically vote, I guess I will now:
> > > > I'm going to give it a -1, pending the resolution the following
> > > > issues, and for an opportunity to correct the minor
> punctuation/typos.
> > > >
> > > > Specifically, I'd like these addressed before I change my vote:
> > > > 1) clarification of whether the ACTIONS list is comprehensive
> > > > 2) clarify reinstatement in the absence of a lack of removal
> procedures
> > > > 3) codebase defined (or at least, Adoption of New Codebase clarified)
> > > > 4) remove "release plan" as requiring a vote (or discuss), because
> > > > while it is nice to coordinate release candidates through a release
> > > > manager, I'm not sure it should be strictly necessary that release
> > > > candidates be planned, or limited to that release manager.
> > > >
> > > >
> > > > --
> > > > Christopher L Tubbs II
> > > > http://gravatar.com/ctubbsii
> > > >
> > > >
> > > > On Mon, Mar 10, 2014 at 5:08 PM, Christopher <ct...@apache.org>
> > > wrote:
> > > > > ***Punctuation:
> > > > >
> > > > > PMC section:
> > > > > "PMC from a Foundation perspective is" -> "PMC, from a Foundation
> > > > > perspective, is"
> > > > > "Secondly " -> "Secondly, "
> > > > > "long term" -> "long-term"
> > > > > "not coding - but to ensure" -> "not coding, but to ensure"
> > > > > "Within the ASF we worry" -> "Within the ASF, we worry"
> > > > >
> > > > > VETOES section (comma):
> > > > > "veto - merely that" -> "veto, merely that"
> > > > >
> > > > > ***Typos:
> > > > >
> > > > > APPROVALS section (typo):
> > > > > "that -1 votes" -> "than -1 votes"
> > > > >
> > > > > ***Definitions:
> > > > > I would like to see "codebase" defined. It's used throughout, but
> is
> > > > > never clearly defined... particularly in the "Adoption of New
> > > > > Codebase" section of the ACTIONS section.
> > > > >
> > > > > ***Other:
> > > > > In the ACTIONS section, it describes reinstatement actions, but not
> > > > > removal actions, so it's not clear what reinstatement means.
> > > > >
> > > > > It should also be made clear that the ACTIONS section is not a
> > > > > comprehensive list of actions.
> > > > >
> > > > > I'm also not sure that the "Release plan" should require a vote, as
> > > > > this seems covered by the "Product release" situation. The other
> > > > > actions seem to imply a vote is required for that action. Are we
> > > > > saying that planning to release requires a vote? If so, I can get
> on
> > > > > board... I just don't remember that happening in the past, so this
> > > > > isn't so much a formalization of our existing practices, but also
> > > > > establishing a new one as well. And, in this case, I'm not sure
> it's
> > > > > one we need.
> > > > >
> > > > > --
> > > > > Christopher L Tubbs II
> > > > > http://gravatar.com/ctubbsii
> > > > >
> >
>
Re: [DISCUSS] Accumulo Bylaw fixes
Posted by Josh Elser <jo...@gmail.com>.
On 3/12/14, 1:17 PM, Bill Havanki wrote:
>> Should the release manager have sole responsibility for determining
>> >whether a major feature makes it into the release if the feature isn't
> quite
>> >ready, or should it require a vote?
> That is a good question. At least for a major release, the beginning of the
> release process = feature freeze. [1] I like the idea of a vote to replan,
> to cancel the current release process and start over. That could be useful
> in other scenarios, like changing a target release date.
Agreed on the vote. I didn't like the idea of giving an RM authority
over the greater community. I much prefer considering the RM as the
guiding force for a release rather than some authoritative entity. The
community at large should still be responsible for releases, but an
elected entity is a good idea to keep the community honest.
Re: [DISCUSS] Accumulo Bylaw fixes
Posted by Bill Havanki <bh...@clouderagovt.com>.
> I think it makes sense to separate the technical aspects and requirements
> of a release from a list of suggestions for the release manager (and the
> community) about how to get things done when leading up to a release (X
> can happen, and Y are some possible ways of dealing with it).
I agree. I think of it as mechanical steps, such as how to tag a release,
vs. procedural steps, like how to judge commits after feature freeze, say.
> Here's a question: should the release plan contain a list of major
features
> intended for the release?
I personally wouldn't be interested in having a feature list in the release
plan. There would already be a CHANGES doc and release notes by the end,
and the vote to start the release process would involve discussing which
features go into it.
> Should the release manager have sole responsibility for determining
> whether a major feature makes it into the release if the feature isn't
quite
> ready, or should it require a vote?
That is a good question. At least for a major release, the beginning of the
release process = feature freeze. [1] I like the idea of a vote to replan,
to cancel the current release process and start over. That could be useful
in other scenarios, like changing a target release date.
[1] http://accumulo.apache.org/governance/releasing.html
-
On Wed, Mar 12, 2014 at 12:47 PM, Billie Rinaldi
<bi...@gmail.com>wrote:
> On Wed, Mar 12, 2014 at 8:54 AM, Bill Havanki <bhavanki@clouderagovt.com
> >wrote:
>
> > The idea of "guidelines" brings to mind the Pirate Code :)
> >
> > https://www.youtube.com/watch?v=b6kgS_AwuH0
> >
> > Release guidelines do exist [1] and your suggestions seem to me good
> > additions to them.
>
>
> I think it makes sense to separate the technical aspects and requirements
> of a release from a list of suggestions for the release manager (and the
> community) about how to get things done when leading up to a release (X can
> happen, and Y are some possible ways of dealing with it). Maybe the things
> I listed don't all fit in the latter category.
>
> Based on Mike's and Bill's discussions, I am +1 for requiring a release
> manager and plan. I think having a release plan template is a very good
> idea, and I like Mike's suggested addition of "A release plan consists of
> ..." to the bylaws. We're probably going to need a "release manager
> responsibilities" section at some point, but maybe not in the first draft.
>
> Here's a question: should the release plan contain a list of major features
> intended for the release? Should the release manager have sole
> responsibility for determining whether a major feature makes it into the
> release if the feature isn't quite ready, or should it require a vote?
>
>
> > There are also some procedures defined there and
> > elsewhere [2] [3] [4] on how mechanically to do a release. However, I see
> > nothing declaring, for example:
> >
> > - that the release manager does much more than package and sign the code
> > and call votes on RCs
> > - that we pick a date for code freeze, or even use one, and what it means
> > - that we pick a target date for release
> > - what a release manager is entitled to do to get the release done
> > - how we ensure that required testing has happened
> > - who is responsible for testing
> >
> > There may be agreed-upon customs for all of the above; if so, they should
> > be codified, and more than just as guidelines. An actual plan gives us
> > rigor. We will be consistent between releases, and have a stable baseline
> > for improving over time. A plan clears up ambiguities, saying who needs
> to
> > do what, and what does not need to be done. It helps newbies like me
> > understand what's going on. It's something we can give out as a service
> to
> > the community, so that users can plan ahead, and know what we promise to
> do
> > for them.
> >
> > I wouldn't expect a release plan to be more than, as I said, a
> boilerplate
> > with filled-in blanks: RM is this person, feature freeze then, code
> freeze
> > then, release by then, everything else follows the general, standard
> rules.
> > Then lazy consensus would be a great voting choice.
> >
> > Having no plan to shoot for makes all the goal dates very soft and prone
> to
> > delay. No one knows when we'll be done and can move on. There's no
> > motivation. Overall, it doesn't make sense to me to say, "Let's not
> plan."
> > :)
> >
> > [1] http://accumulo.apache.org/governance/releasing.html
> > [2] http://accumulo.apache.org/releasing.html
> > [3] https://www.apache.org/dev/release-publishing.html
> > [4] http://www.apache.org/dev/release.html
> >
> >
> > On Wed, Mar 12, 2014 at 10:50 AM, Billie Rinaldi
> > <bi...@gmail.com>wrote:
> >
> > > I disagree with Mike on point 4. This is not a matter of people not
> > having
> > > authority, and I don't see a lack of release plans / managers as the
> > > problem behind our major releases not occurring as often as we'd like.
> I
> > > wouldn't be opposed to adding a release plan / manager vote as an
> > optional
> > > step that can be taken when preparing for a release (perhaps a strongly
> > > encouraged or even required step when it's a major release). I also
> > think
> > > we should consider making the vote lazy consensus, falling back to
> > majority
> > > approval if a -1 is received.
> > >
> > > However, adding this step will not solve our release woes. Perhaps
> > > something that might help would be to develop a set of suggested
> > guidelines
> > > to follow or strategies to take when working towards the final stages
> of
> > a
> > > release, post code freeze. At least some of these should be
> > > responsibilities of all committers, not just a release manager.
> > >
> > > Some guesses for what could go on this list:
> > > - always select a new date when a previously selected date has passed
> > > - initiate discussion of remaining tickets / tasks regularly (every
> > week?)
> > > - once a .0-SNAPSHOT branch has been created, every committer should
> > follow
> > > some specified procedure before committing changes to it (I don't mean
> a
> > > voting procedure, more like soul-searching -- or perhaps a simple
> > > flowchart: Are you committing this change against a blocker or
> > > documentation-only ticket? No => Don't commit or merge it to this
> > branch).
> > >
> > > Any thoughts or other suggestions on strategies to document?
> > >
> > >
> > >
> > > On Tue, Mar 11, 2014 at 1:20 PM, Sean Busbey <
> busbey+lists@cloudera.com
> > > >wrote:
> > >
> > > > Moving this over to its own DISCUSS thread so we can keep the VOTE
> > easier
> > > > to follow.
> > > >
> > > > wrt #4, I'm with Mike on this. One of our big problems, as a
> community,
> > > is
> > > > lack of steady release cadence. Even once we decide on a feature
> > freeze,
> > > we
> > > > don't have enough rigor in driving to release. For example, 1.6.0 hit
> > > > feature freeze 4.5 months ago[1]. I think John is doing fine given
> the
> > > > circumstances, but without a date to drive towards it's hard to
> justify
> > > > throwing stuff off the raft.
> > > >
> > > > Since we'll presumably be updating the bylaws for the next vote, I'd
> > like
> > > > to see a definition for the Release Manager role since we reference
> it.
> > > >
> > > > [1]: http://s.apache.org/accumulo_1.6.0_feature_freeze_vote
> > > >
> > > > -Sean
> > > >
> > > > On Tue, Mar 11, 2014 at 1:17 PM, Mike Drob <ma...@cloudera.com>
> > wrote:
> > > >
> > > > > 1) Agree w/ Bill.
> > > > >
> > > > > 2) Agree w/ Bill.
> > > > >
> > > > > 3) In my understanding, codebase includes the site svn, the primary
> > git
> > > > > repository, and all contrib repositories. Adoption of a new
> codebase
> > > > > generally refers to the creation of a new contrib repository.
> > However,
> > > I
> > > > > could see it also expanded to cover things like re-doing the entire
> > > site
> > > > > look and feel, or merging a contrib project into the primary
> > codebase.
> > > > > Christopher, do you have any proposed verbiage that you would like
> to
> > > see
> > > > > specifically?
> > > > >
> > > > > 4) I very much disagree, Christopher. Having a dedicated release
> > > manager
> > > > is
> > > > > critical to having a release occur in a timely manner. Further, the
> > > > > community needs to be able to make hard decisions, like setting a
> > > feature
> > > > > or code freeze date, or pulling incomplete work out of a branch.
> > Right
> > > > now,
> > > > > we have release managers in name only, and I would love to see us
> > give
> > > > them
> > > > > more authority on performing the release - right now we have a
> steady
> > > > > stream of small changes that developers feel should be exempt from
> > the
> > > > > freeze, something I'm guilty of myself as well. I see the lack of a
> > > > > formalized release plan as one reason for why releases tend to drag
> > on
> > > > for
> > > > > far too long.
> > > > >
> > > > > In short, if we don't have a release manager pushing for them, then
> > > > > releases just won't happen. It's a gruelling task, and we need to
> > have
> > > > > procedure to bless somebody to do it.
> > > > >
> > > > >
> > > > > Mike
> > > > >
> > > > >
> > > > > On Mon, Mar 10, 2014 at 11:03 PM, Bill Havanki <
> > > > bhavanki@clouderagovt.com
> > > > > >wrote:
> > > > >
> > > > > > My sense from the conversations leading up to the vote:
> > > > > >
> > > > > > 1) I believe the list is comprehensive, in that no other voting
> > > actions
> > > > > are
> > > > > > contemplated. If we realize we need a new one, we can add it
> later.
> > > > > >
> > > > > > 2) We determined that a committer, by ASF rules, cannot truly
> lose
> > > > > > committer status [1], so no removal procedure is defined. Removal
> > of
> > > a
> > > > > PMC
> > > > > > member is up to the ASF Board [2], so no procedure is defined.
> > > > > >
> > > > > > 3) I see no harm in adding a definition.
> > > > > >
> > > > > > 4) I think the "release plan" is the process for cutting a
> release,
> > > > while
> > > > > > "product release" is for approving a specific RC as the release.
> > For
> > > > me,
> > > > > a
> > > > > > boilerplate release plan with customizations (who is the RM, what
> > > tests
> > > > > are
> > > > > > needed, time frame for freezes, etc.) would be nice to have laid
> > out.
> > > > > >
> > > > > > [1] http://www.apache.org/dev/committers.html#committer-set-term
> > > > > > [2] http://www.apache.org/dev/pmc.html#pmc-removal
> > > > > >
> > > > > >
> > > > > > On Mon, Mar 10, 2014 at 5:52 PM, Christopher <
> ctubbsii@apache.org>
> > > > > wrote:
> > > > > >
> > > > > > > Since I didn't technically vote, I guess I will now:
> > > > > > > I'm going to give it a -1, pending the resolution the following
> > > > > > > issues, and for an opportunity to correct the minor
> > > > punctuation/typos.
> > > > > > >
> > > > > > > Specifically, I'd like these addressed before I change my vote:
> > > > > > > 1) clarification of whether the ACTIONS list is comprehensive
> > > > > > > 2) clarify reinstatement in the absence of a lack of removal
> > > > procedures
> > > > > > > 3) codebase defined (or at least, Adoption of New Codebase
> > > clarified)
> > > > > > > 4) remove "release plan" as requiring a vote (or discuss),
> > because
> > > > > > > while it is nice to coordinate release candidates through a
> > release
> > > > > > > manager, I'm not sure it should be strictly necessary that
> > release
> > > > > > > candidates be planned, or limited to that release manager.
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Christopher L Tubbs II
> > > > > > > http://gravatar.com/ctubbsii
> > > > > > >
> > > > > > >
> > > > > > > On Mon, Mar 10, 2014 at 5:08 PM, Christopher <
> > ctubbsii@apache.org>
> > > > > > wrote:
> > > > > > > > ***Punctuation:
> > > > > > > >
> > > > > > > > PMC section:
> > > > > > > > "PMC from a Foundation perspective is" -> "PMC, from a
> > Foundation
> > > > > > > > perspective, is"
> > > > > > > > "Secondly " -> "Secondly, "
> > > > > > > > "long term" -> "long-term"
> > > > > > > > "not coding - but to ensure" -> "not coding, but to ensure"
> > > > > > > > "Within the ASF we worry" -> "Within the ASF, we worry"
> > > > > > > >
> > > > > > > > VETOES section (comma):
> > > > > > > > "veto - merely that" -> "veto, merely that"
> > > > > > > >
> > > > > > > > ***Typos:
> > > > > > > >
> > > > > > > > APPROVALS section (typo):
> > > > > > > > "that -1 votes" -> "than -1 votes"
> > > > > > > >
> > > > > > > > ***Definitions:
> > > > > > > > I would like to see "codebase" defined. It's used throughout,
> > but
> > > > is
> > > > > > > > never clearly defined... particularly in the "Adoption of New
> > > > > > > > Codebase" section of the ACTIONS section.
> > > > > > > >
> > > > > > > > ***Other:
> > > > > > > > In the ACTIONS section, it describes reinstatement actions,
> but
> > > not
> > > > > > > > removal actions, so it's not clear what reinstatement means.
> > > > > > > >
> > > > > > > > It should also be made clear that the ACTIONS section is not
> a
> > > > > > > > comprehensive list of actions.
> > > > > > > >
> > > > > > > > I'm also not sure that the "Release plan" should require a
> > vote,
> > > as
> > > > > > > > this seems covered by the "Product release" situation. The
> > other
> > > > > > > > actions seem to imply a vote is required for that action. Are
> > we
> > > > > > > > saying that planning to release requires a vote? If so, I can
> > get
> > > > on
> > > > > > > > board... I just don't remember that happening in the past, so
> > > this
> > > > > > > > isn't so much a formalization of our existing practices, but
> > also
> > > > > > > > establishing a new one as well. And, in this case, I'm not
> sure
> > > > it's
> > > > > > > > one we need.
> > > > > > > >
> > > > > > > > --
> > > > > > > > Christopher L Tubbs II
> > > > > > > > http://gravatar.com/ctubbsii
> > > > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > // Bill Havanki
> > // Solutions Architect, Cloudera Govt Solutions
> > // 443.686.9283
> >
>
--
// Bill Havanki
// Solutions Architect, Cloudera Govt Solutions
// 443.686.9283
Re: [DISCUSS] Accumulo Bylaw fixes
Posted by Billie Rinaldi <bi...@gmail.com>.
On Wed, Mar 12, 2014 at 8:54 AM, Bill Havanki <bh...@clouderagovt.com>wrote:
> The idea of "guidelines" brings to mind the Pirate Code :)
>
> https://www.youtube.com/watch?v=b6kgS_AwuH0
>
> Release guidelines do exist [1] and your suggestions seem to me good
> additions to them.
I think it makes sense to separate the technical aspects and requirements
of a release from a list of suggestions for the release manager (and the
community) about how to get things done when leading up to a release (X can
happen, and Y are some possible ways of dealing with it). Maybe the things
I listed don't all fit in the latter category.
Based on Mike's and Bill's discussions, I am +1 for requiring a release
manager and plan. I think having a release plan template is a very good
idea, and I like Mike's suggested addition of "A release plan consists of
..." to the bylaws. We're probably going to need a "release manager
responsibilities" section at some point, but maybe not in the first draft.
Here's a question: should the release plan contain a list of major features
intended for the release? Should the release manager have sole
responsibility for determining whether a major feature makes it into the
release if the feature isn't quite ready, or should it require a vote?
> There are also some procedures defined there and
> elsewhere [2] [3] [4] on how mechanically to do a release. However, I see
> nothing declaring, for example:
>
> - that the release manager does much more than package and sign the code
> and call votes on RCs
> - that we pick a date for code freeze, or even use one, and what it means
> - that we pick a target date for release
> - what a release manager is entitled to do to get the release done
> - how we ensure that required testing has happened
> - who is responsible for testing
>
> There may be agreed-upon customs for all of the above; if so, they should
> be codified, and more than just as guidelines. An actual plan gives us
> rigor. We will be consistent between releases, and have a stable baseline
> for improving over time. A plan clears up ambiguities, saying who needs to
> do what, and what does not need to be done. It helps newbies like me
> understand what's going on. It's something we can give out as a service to
> the community, so that users can plan ahead, and know what we promise to do
> for them.
>
> I wouldn't expect a release plan to be more than, as I said, a boilerplate
> with filled-in blanks: RM is this person, feature freeze then, code freeze
> then, release by then, everything else follows the general, standard rules.
> Then lazy consensus would be a great voting choice.
>
> Having no plan to shoot for makes all the goal dates very soft and prone to
> delay. No one knows when we'll be done and can move on. There's no
> motivation. Overall, it doesn't make sense to me to say, "Let's not plan."
> :)
>
> [1] http://accumulo.apache.org/governance/releasing.html
> [2] http://accumulo.apache.org/releasing.html
> [3] https://www.apache.org/dev/release-publishing.html
> [4] http://www.apache.org/dev/release.html
>
>
> On Wed, Mar 12, 2014 at 10:50 AM, Billie Rinaldi
> <bi...@gmail.com>wrote:
>
> > I disagree with Mike on point 4. This is not a matter of people not
> having
> > authority, and I don't see a lack of release plans / managers as the
> > problem behind our major releases not occurring as often as we'd like. I
> > wouldn't be opposed to adding a release plan / manager vote as an
> optional
> > step that can be taken when preparing for a release (perhaps a strongly
> > encouraged or even required step when it's a major release). I also
> think
> > we should consider making the vote lazy consensus, falling back to
> majority
> > approval if a -1 is received.
> >
> > However, adding this step will not solve our release woes. Perhaps
> > something that might help would be to develop a set of suggested
> guidelines
> > to follow or strategies to take when working towards the final stages of
> a
> > release, post code freeze. At least some of these should be
> > responsibilities of all committers, not just a release manager.
> >
> > Some guesses for what could go on this list:
> > - always select a new date when a previously selected date has passed
> > - initiate discussion of remaining tickets / tasks regularly (every
> week?)
> > - once a .0-SNAPSHOT branch has been created, every committer should
> follow
> > some specified procedure before committing changes to it (I don't mean a
> > voting procedure, more like soul-searching -- or perhaps a simple
> > flowchart: Are you committing this change against a blocker or
> > documentation-only ticket? No => Don't commit or merge it to this
> branch).
> >
> > Any thoughts or other suggestions on strategies to document?
> >
> >
> >
> > On Tue, Mar 11, 2014 at 1:20 PM, Sean Busbey <busbey+lists@cloudera.com
> > >wrote:
> >
> > > Moving this over to its own DISCUSS thread so we can keep the VOTE
> easier
> > > to follow.
> > >
> > > wrt #4, I'm with Mike on this. One of our big problems, as a community,
> > is
> > > lack of steady release cadence. Even once we decide on a feature
> freeze,
> > we
> > > don't have enough rigor in driving to release. For example, 1.6.0 hit
> > > feature freeze 4.5 months ago[1]. I think John is doing fine given the
> > > circumstances, but without a date to drive towards it's hard to justify
> > > throwing stuff off the raft.
> > >
> > > Since we'll presumably be updating the bylaws for the next vote, I'd
> like
> > > to see a definition for the Release Manager role since we reference it.
> > >
> > > [1]: http://s.apache.org/accumulo_1.6.0_feature_freeze_vote
> > >
> > > -Sean
> > >
> > > On Tue, Mar 11, 2014 at 1:17 PM, Mike Drob <ma...@cloudera.com>
> wrote:
> > >
> > > > 1) Agree w/ Bill.
> > > >
> > > > 2) Agree w/ Bill.
> > > >
> > > > 3) In my understanding, codebase includes the site svn, the primary
> git
> > > > repository, and all contrib repositories. Adoption of a new codebase
> > > > generally refers to the creation of a new contrib repository.
> However,
> > I
> > > > could see it also expanded to cover things like re-doing the entire
> > site
> > > > look and feel, or merging a contrib project into the primary
> codebase.
> > > > Christopher, do you have any proposed verbiage that you would like to
> > see
> > > > specifically?
> > > >
> > > > 4) I very much disagree, Christopher. Having a dedicated release
> > manager
> > > is
> > > > critical to having a release occur in a timely manner. Further, the
> > > > community needs to be able to make hard decisions, like setting a
> > feature
> > > > or code freeze date, or pulling incomplete work out of a branch.
> Right
> > > now,
> > > > we have release managers in name only, and I would love to see us
> give
> > > them
> > > > more authority on performing the release - right now we have a steady
> > > > stream of small changes that developers feel should be exempt from
> the
> > > > freeze, something I'm guilty of myself as well. I see the lack of a
> > > > formalized release plan as one reason for why releases tend to drag
> on
> > > for
> > > > far too long.
> > > >
> > > > In short, if we don't have a release manager pushing for them, then
> > > > releases just won't happen. It's a gruelling task, and we need to
> have
> > > > procedure to bless somebody to do it.
> > > >
> > > >
> > > > Mike
> > > >
> > > >
> > > > On Mon, Mar 10, 2014 at 11:03 PM, Bill Havanki <
> > > bhavanki@clouderagovt.com
> > > > >wrote:
> > > >
> > > > > My sense from the conversations leading up to the vote:
> > > > >
> > > > > 1) I believe the list is comprehensive, in that no other voting
> > actions
> > > > are
> > > > > contemplated. If we realize we need a new one, we can add it later.
> > > > >
> > > > > 2) We determined that a committer, by ASF rules, cannot truly lose
> > > > > committer status [1], so no removal procedure is defined. Removal
> of
> > a
> > > > PMC
> > > > > member is up to the ASF Board [2], so no procedure is defined.
> > > > >
> > > > > 3) I see no harm in adding a definition.
> > > > >
> > > > > 4) I think the "release plan" is the process for cutting a release,
> > > while
> > > > > "product release" is for approving a specific RC as the release.
> For
> > > me,
> > > > a
> > > > > boilerplate release plan with customizations (who is the RM, what
> > tests
> > > > are
> > > > > needed, time frame for freezes, etc.) would be nice to have laid
> out.
> > > > >
> > > > > [1] http://www.apache.org/dev/committers.html#committer-set-term
> > > > > [2] http://www.apache.org/dev/pmc.html#pmc-removal
> > > > >
> > > > >
> > > > > On Mon, Mar 10, 2014 at 5:52 PM, Christopher <ct...@apache.org>
> > > > wrote:
> > > > >
> > > > > > Since I didn't technically vote, I guess I will now:
> > > > > > I'm going to give it a -1, pending the resolution the following
> > > > > > issues, and for an opportunity to correct the minor
> > > punctuation/typos.
> > > > > >
> > > > > > Specifically, I'd like these addressed before I change my vote:
> > > > > > 1) clarification of whether the ACTIONS list is comprehensive
> > > > > > 2) clarify reinstatement in the absence of a lack of removal
> > > procedures
> > > > > > 3) codebase defined (or at least, Adoption of New Codebase
> > clarified)
> > > > > > 4) remove "release plan" as requiring a vote (or discuss),
> because
> > > > > > while it is nice to coordinate release candidates through a
> release
> > > > > > manager, I'm not sure it should be strictly necessary that
> release
> > > > > > candidates be planned, or limited to that release manager.
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Christopher L Tubbs II
> > > > > > http://gravatar.com/ctubbsii
> > > > > >
> > > > > >
> > > > > > On Mon, Mar 10, 2014 at 5:08 PM, Christopher <
> ctubbsii@apache.org>
> > > > > wrote:
> > > > > > > ***Punctuation:
> > > > > > >
> > > > > > > PMC section:
> > > > > > > "PMC from a Foundation perspective is" -> "PMC, from a
> Foundation
> > > > > > > perspective, is"
> > > > > > > "Secondly " -> "Secondly, "
> > > > > > > "long term" -> "long-term"
> > > > > > > "not coding - but to ensure" -> "not coding, but to ensure"
> > > > > > > "Within the ASF we worry" -> "Within the ASF, we worry"
> > > > > > >
> > > > > > > VETOES section (comma):
> > > > > > > "veto - merely that" -> "veto, merely that"
> > > > > > >
> > > > > > > ***Typos:
> > > > > > >
> > > > > > > APPROVALS section (typo):
> > > > > > > "that -1 votes" -> "than -1 votes"
> > > > > > >
> > > > > > > ***Definitions:
> > > > > > > I would like to see "codebase" defined. It's used throughout,
> but
> > > is
> > > > > > > never clearly defined... particularly in the "Adoption of New
> > > > > > > Codebase" section of the ACTIONS section.
> > > > > > >
> > > > > > > ***Other:
> > > > > > > In the ACTIONS section, it describes reinstatement actions, but
> > not
> > > > > > > removal actions, so it's not clear what reinstatement means.
> > > > > > >
> > > > > > > It should also be made clear that the ACTIONS section is not a
> > > > > > > comprehensive list of actions.
> > > > > > >
> > > > > > > I'm also not sure that the "Release plan" should require a
> vote,
> > as
> > > > > > > this seems covered by the "Product release" situation. The
> other
> > > > > > > actions seem to imply a vote is required for that action. Are
> we
> > > > > > > saying that planning to release requires a vote? If so, I can
> get
> > > on
> > > > > > > board... I just don't remember that happening in the past, so
> > this
> > > > > > > isn't so much a formalization of our existing practices, but
> also
> > > > > > > establishing a new one as well. And, in this case, I'm not sure
> > > it's
> > > > > > > one we need.
> > > > > > >
> > > > > > > --
> > > > > > > Christopher L Tubbs II
> > > > > > > http://gravatar.com/ctubbsii
> > > > > > >
> > > >
> > >
> >
>
>
>
> --
> // Bill Havanki
> // Solutions Architect, Cloudera Govt Solutions
> // 443.686.9283
>
Re: [DISCUSS] Accumulo Bylaw fixes
Posted by Bill Havanki <bh...@clouderagovt.com>.
The idea of "guidelines" brings to mind the Pirate Code :)
https://www.youtube.com/watch?v=b6kgS_AwuH0
Release guidelines do exist [1] and your suggestions seem to me good
additions to them. There are also some procedures defined there and
elsewhere [2] [3] [4] on how mechanically to do a release. However, I see
nothing declaring, for example:
- that the release manager does much more than package and sign the code
and call votes on RCs
- that we pick a date for code freeze, or even use one, and what it means
- that we pick a target date for release
- what a release manager is entitled to do to get the release done
- how we ensure that required testing has happened
- who is responsible for testing
There may be agreed-upon customs for all of the above; if so, they should
be codified, and more than just as guidelines. An actual plan gives us
rigor. We will be consistent between releases, and have a stable baseline
for improving over time. A plan clears up ambiguities, saying who needs to
do what, and what does not need to be done. It helps newbies like me
understand what's going on. It's something we can give out as a service to
the community, so that users can plan ahead, and know what we promise to do
for them.
I wouldn't expect a release plan to be more than, as I said, a boilerplate
with filled-in blanks: RM is this person, feature freeze then, code freeze
then, release by then, everything else follows the general, standard rules.
Then lazy consensus would be a great voting choice.
Having no plan to shoot for makes all the goal dates very soft and prone to
delay. No one knows when we'll be done and can move on. There's no
motivation. Overall, it doesn't make sense to me to say, "Let's not plan."
:)
[1] http://accumulo.apache.org/governance/releasing.html
[2] http://accumulo.apache.org/releasing.html
[3] https://www.apache.org/dev/release-publishing.html
[4] http://www.apache.org/dev/release.html
On Wed, Mar 12, 2014 at 10:50 AM, Billie Rinaldi
<bi...@gmail.com>wrote:
> I disagree with Mike on point 4. This is not a matter of people not having
> authority, and I don't see a lack of release plans / managers as the
> problem behind our major releases not occurring as often as we'd like. I
> wouldn't be opposed to adding a release plan / manager vote as an optional
> step that can be taken when preparing for a release (perhaps a strongly
> encouraged or even required step when it's a major release). I also think
> we should consider making the vote lazy consensus, falling back to majority
> approval if a -1 is received.
>
> However, adding this step will not solve our release woes. Perhaps
> something that might help would be to develop a set of suggested guidelines
> to follow or strategies to take when working towards the final stages of a
> release, post code freeze. At least some of these should be
> responsibilities of all committers, not just a release manager.
>
> Some guesses for what could go on this list:
> - always select a new date when a previously selected date has passed
> - initiate discussion of remaining tickets / tasks regularly (every week?)
> - once a .0-SNAPSHOT branch has been created, every committer should follow
> some specified procedure before committing changes to it (I don't mean a
> voting procedure, more like soul-searching -- or perhaps a simple
> flowchart: Are you committing this change against a blocker or
> documentation-only ticket? No => Don't commit or merge it to this branch).
>
> Any thoughts or other suggestions on strategies to document?
>
>
>
> On Tue, Mar 11, 2014 at 1:20 PM, Sean Busbey <busbey+lists@cloudera.com
> >wrote:
>
> > Moving this over to its own DISCUSS thread so we can keep the VOTE easier
> > to follow.
> >
> > wrt #4, I'm with Mike on this. One of our big problems, as a community,
> is
> > lack of steady release cadence. Even once we decide on a feature freeze,
> we
> > don't have enough rigor in driving to release. For example, 1.6.0 hit
> > feature freeze 4.5 months ago[1]. I think John is doing fine given the
> > circumstances, but without a date to drive towards it's hard to justify
> > throwing stuff off the raft.
> >
> > Since we'll presumably be updating the bylaws for the next vote, I'd like
> > to see a definition for the Release Manager role since we reference it.
> >
> > [1]: http://s.apache.org/accumulo_1.6.0_feature_freeze_vote
> >
> > -Sean
> >
> > On Tue, Mar 11, 2014 at 1:17 PM, Mike Drob <ma...@cloudera.com> wrote:
> >
> > > 1) Agree w/ Bill.
> > >
> > > 2) Agree w/ Bill.
> > >
> > > 3) In my understanding, codebase includes the site svn, the primary git
> > > repository, and all contrib repositories. Adoption of a new codebase
> > > generally refers to the creation of a new contrib repository. However,
> I
> > > could see it also expanded to cover things like re-doing the entire
> site
> > > look and feel, or merging a contrib project into the primary codebase.
> > > Christopher, do you have any proposed verbiage that you would like to
> see
> > > specifically?
> > >
> > > 4) I very much disagree, Christopher. Having a dedicated release
> manager
> > is
> > > critical to having a release occur in a timely manner. Further, the
> > > community needs to be able to make hard decisions, like setting a
> feature
> > > or code freeze date, or pulling incomplete work out of a branch. Right
> > now,
> > > we have release managers in name only, and I would love to see us give
> > them
> > > more authority on performing the release - right now we have a steady
> > > stream of small changes that developers feel should be exempt from the
> > > freeze, something I'm guilty of myself as well. I see the lack of a
> > > formalized release plan as one reason for why releases tend to drag on
> > for
> > > far too long.
> > >
> > > In short, if we don't have a release manager pushing for them, then
> > > releases just won't happen. It's a gruelling task, and we need to have
> > > procedure to bless somebody to do it.
> > >
> > >
> > > Mike
> > >
> > >
> > > On Mon, Mar 10, 2014 at 11:03 PM, Bill Havanki <
> > bhavanki@clouderagovt.com
> > > >wrote:
> > >
> > > > My sense from the conversations leading up to the vote:
> > > >
> > > > 1) I believe the list is comprehensive, in that no other voting
> actions
> > > are
> > > > contemplated. If we realize we need a new one, we can add it later.
> > > >
> > > > 2) We determined that a committer, by ASF rules, cannot truly lose
> > > > committer status [1], so no removal procedure is defined. Removal of
> a
> > > PMC
> > > > member is up to the ASF Board [2], so no procedure is defined.
> > > >
> > > > 3) I see no harm in adding a definition.
> > > >
> > > > 4) I think the "release plan" is the process for cutting a release,
> > while
> > > > "product release" is for approving a specific RC as the release. For
> > me,
> > > a
> > > > boilerplate release plan with customizations (who is the RM, what
> tests
> > > are
> > > > needed, time frame for freezes, etc.) would be nice to have laid out.
> > > >
> > > > [1] http://www.apache.org/dev/committers.html#committer-set-term
> > > > [2] http://www.apache.org/dev/pmc.html#pmc-removal
> > > >
> > > >
> > > > On Mon, Mar 10, 2014 at 5:52 PM, Christopher <ct...@apache.org>
> > > wrote:
> > > >
> > > > > Since I didn't technically vote, I guess I will now:
> > > > > I'm going to give it a -1, pending the resolution the following
> > > > > issues, and for an opportunity to correct the minor
> > punctuation/typos.
> > > > >
> > > > > Specifically, I'd like these addressed before I change my vote:
> > > > > 1) clarification of whether the ACTIONS list is comprehensive
> > > > > 2) clarify reinstatement in the absence of a lack of removal
> > procedures
> > > > > 3) codebase defined (or at least, Adoption of New Codebase
> clarified)
> > > > > 4) remove "release plan" as requiring a vote (or discuss), because
> > > > > while it is nice to coordinate release candidates through a release
> > > > > manager, I'm not sure it should be strictly necessary that release
> > > > > candidates be planned, or limited to that release manager.
> > > > >
> > > > >
> > > > > --
> > > > > Christopher L Tubbs II
> > > > > http://gravatar.com/ctubbsii
> > > > >
> > > > >
> > > > > On Mon, Mar 10, 2014 at 5:08 PM, Christopher <ct...@apache.org>
> > > > wrote:
> > > > > > ***Punctuation:
> > > > > >
> > > > > > PMC section:
> > > > > > "PMC from a Foundation perspective is" -> "PMC, from a Foundation
> > > > > > perspective, is"
> > > > > > "Secondly " -> "Secondly, "
> > > > > > "long term" -> "long-term"
> > > > > > "not coding - but to ensure" -> "not coding, but to ensure"
> > > > > > "Within the ASF we worry" -> "Within the ASF, we worry"
> > > > > >
> > > > > > VETOES section (comma):
> > > > > > "veto - merely that" -> "veto, merely that"
> > > > > >
> > > > > > ***Typos:
> > > > > >
> > > > > > APPROVALS section (typo):
> > > > > > "that -1 votes" -> "than -1 votes"
> > > > > >
> > > > > > ***Definitions:
> > > > > > I would like to see "codebase" defined. It's used throughout, but
> > is
> > > > > > never clearly defined... particularly in the "Adoption of New
> > > > > > Codebase" section of the ACTIONS section.
> > > > > >
> > > > > > ***Other:
> > > > > > In the ACTIONS section, it describes reinstatement actions, but
> not
> > > > > > removal actions, so it's not clear what reinstatement means.
> > > > > >
> > > > > > It should also be made clear that the ACTIONS section is not a
> > > > > > comprehensive list of actions.
> > > > > >
> > > > > > I'm also not sure that the "Release plan" should require a vote,
> as
> > > > > > this seems covered by the "Product release" situation. The other
> > > > > > actions seem to imply a vote is required for that action. Are we
> > > > > > saying that planning to release requires a vote? If so, I can get
> > on
> > > > > > board... I just don't remember that happening in the past, so
> this
> > > > > > isn't so much a formalization of our existing practices, but also
> > > > > > establishing a new one as well. And, in this case, I'm not sure
> > it's
> > > > > > one we need.
> > > > > >
> > > > > > --
> > > > > > Christopher L Tubbs II
> > > > > > http://gravatar.com/ctubbsii
> > > > > >
> > >
> >
>
--
// Bill Havanki
// Solutions Architect, Cloudera Govt Solutions
// 443.686.9283
Re: [DISCUSS] Accumulo Bylaw fixes
Posted by Bill Havanki <bh...@clouderagovt.com>.
I always remind myself that we aren't going to run out of numbers. If some
feature doesn't make it in release X, there is always X+1. Heck, X+1 can be
just that feature for all I care. What version of Firefox or Chrome are you
using, and do you care anymore?
I want to avoid the idea that releases must be few and far between, so all
the stars must align perfectly for each. We gotta just ship. Make a plan,
pick a date, go for it, put it to bed, move on.
The idea of clamping down, especially with feature freeze, is indeed to
slow down. That is the cost for stability. The problem right now is that
it's taking weeks or months to orchestrate a release. That is too slow. You
speed it up by limiting the scope. When you get the right speed - a middle
ground between overly long and too quick - good releases can happen more
often, and then you're less likely to want to squeeze more into each
release.
For *bug fixes* - I think they are fine after feature freeze. We should
avoid shipping bugs! :) If some huge bug appears, absolutely, postpone or
cancel the vote, we have problems to deal with. But until then, we can pick
a date, tentative as it may be. Users will be happy to see we have that
goal, so they don't have to read tea leaves. Yet, it's understood it can
change. It's not etched in stone.
On Wed, Mar 12, 2014 at 2:23 PM, Mike Drob <ma...@cloudera.com> wrote:
> Inline.
>
> On Wed, Mar 12, 2014 at 2:16 PM, Josh Elser <jo...@gmail.com> wrote:
>
> > On 3/12/14, 12:09 PM, Mike Drob wrote:
> >
> >> - once a .0-SNAPSHOT branch has been created, every committer should
> >>> follow
> >>> >some specified procedure before committing changes to it (I don't
> mean a
> >>> >voting procedure, more like soul-searching -- or perhaps a simple
> >>> >flowchart: Are you committing this change against a blocker or
> >>> >documentation-only ticket? No => Don't commit or merge it to this
> >>> branch).
> >>> >
> >>>
> >> Soul searching is a very fuzzy concept that I am not comfortable with
> for
> >> being used to drive releases. We've had an implicit (read: unwritten)
> >> policy that only bug fixes can go into release branches, but many
> >> developers (myself included) have stretched both the definition of bug
> and
> >> the definition of fix. I'm completely on board with always making code
> >> better, but it's also good to draw a line in the sand somewhere and
> >> actually make releases.
> >>
> >
> > I think I would actually prefer keeping things looser rather than having
> > to ask permission before making a fix (it just slows things down more).
> > That feels more in line with our CTR. I also don't think we've really
> had a
> > problem in this department before with changes being applied that were
> then
> > reverted (despite lines being stretched).
> >
> > I'm not concerned about the changes that get reverted. That is an example
> of the system working.
>
> I am more concerned about the changes that might need to be reverted, but
> then aren't. Because they're too big, or too complicated, or too messy, or
> too whatever. Or they just need a little bit more work, so don't revert
> them because I'll be done with it next week, I totally promise.
>
> Also, even if the only bug-fixes in release branches wasn't written down, I
> > don't think there is any ambiguity or disagreement on following that.
> >
> >
> > >
> >>> >Any thoughts or other suggestions on strategies to document?
> >>> >
> >>>
> >> Maybe we can add some release plan/manager basics to the bylaws?
> >>
> >> """A release plan consists of:
> >> * a release manager
> >> * a proposed version number
> >> * a feature freeze date (bug fixes and documentation only)
> >> * a code freeze date (documentation only)
> >> * a planned rc vote date
> >>
> >> Should any of these dates be missed, the release manager is responsible
> >> for
> >> selecting new dates."""
> >>
> >
> > A planned RC vote might be a bit aggressive. It's hard to judge whether
> or
> > not CI/RW tests will unearth some unknown bug. I like the other items,
> > though.
> >
>
> I put down a planned RC vote date because that seemed easier than a planned
> release date. I'd be fine with either, but really want to include a goal
> date so that people have something to shoot for once we start the process
> instead of just floundering after feature freeze.
>
--
// Bill Havanki
// Solutions Architect, Cloudera Govt Solutions
// 443.686.9283
Re: [DISCUSS] Accumulo Bylaw fixes
Posted by Mike Drob <ma...@cloudera.com>.
Inline.
On Wed, Mar 12, 2014 at 2:16 PM, Josh Elser <jo...@gmail.com> wrote:
> On 3/12/14, 12:09 PM, Mike Drob wrote:
>
>> - once a .0-SNAPSHOT branch has been created, every committer should
>>> follow
>>> >some specified procedure before committing changes to it (I don't mean a
>>> >voting procedure, more like soul-searching -- or perhaps a simple
>>> >flowchart: Are you committing this change against a blocker or
>>> >documentation-only ticket? No => Don't commit or merge it to this
>>> branch).
>>> >
>>>
>> Soul searching is a very fuzzy concept that I am not comfortable with for
>> being used to drive releases. We've had an implicit (read: unwritten)
>> policy that only bug fixes can go into release branches, but many
>> developers (myself included) have stretched both the definition of bug and
>> the definition of fix. I'm completely on board with always making code
>> better, but it's also good to draw a line in the sand somewhere and
>> actually make releases.
>>
>
> I think I would actually prefer keeping things looser rather than having
> to ask permission before making a fix (it just slows things down more).
> That feels more in line with our CTR. I also don't think we've really had a
> problem in this department before with changes being applied that were then
> reverted (despite lines being stretched).
>
> I'm not concerned about the changes that get reverted. That is an example
of the system working.
I am more concerned about the changes that might need to be reverted, but
then aren't. Because they're too big, or too complicated, or too messy, or
too whatever. Or they just need a little bit more work, so don't revert
them because I'll be done with it next week, I totally promise.
Also, even if the only bug-fixes in release branches wasn't written down, I
> don't think there is any ambiguity or disagreement on following that.
>
>
> >
>>> >Any thoughts or other suggestions on strategies to document?
>>> >
>>>
>> Maybe we can add some release plan/manager basics to the bylaws?
>>
>> """A release plan consists of:
>> * a release manager
>> * a proposed version number
>> * a feature freeze date (bug fixes and documentation only)
>> * a code freeze date (documentation only)
>> * a planned rc vote date
>>
>> Should any of these dates be missed, the release manager is responsible
>> for
>> selecting new dates."""
>>
>
> A planned RC vote might be a bit aggressive. It's hard to judge whether or
> not CI/RW tests will unearth some unknown bug. I like the other items,
> though.
>
I put down a planned RC vote date because that seemed easier than a planned
release date. I'd be fine with either, but really want to include a goal
date so that people have something to shoot for once we start the process
instead of just floundering after feature freeze.
Re: [DISCUSS] Accumulo Bylaw fixes
Posted by Josh Elser <jo...@gmail.com>.
On 3/12/14, 12:09 PM, Mike Drob wrote:
>> - once a .0-SNAPSHOT branch has been created, every committer should follow
>> >some specified procedure before committing changes to it (I don't mean a
>> >voting procedure, more like soul-searching -- or perhaps a simple
>> >flowchart: Are you committing this change against a blocker or
>> >documentation-only ticket? No => Don't commit or merge it to this branch).
>> >
> Soul searching is a very fuzzy concept that I am not comfortable with for
> being used to drive releases. We've had an implicit (read: unwritten)
> policy that only bug fixes can go into release branches, but many
> developers (myself included) have stretched both the definition of bug and
> the definition of fix. I'm completely on board with always making code
> better, but it's also good to draw a line in the sand somewhere and
> actually make releases.
I think I would actually prefer keeping things looser rather than having
to ask permission before making a fix (it just slows things down more).
That feels more in line with our CTR. I also don't think we've really
had a problem in this department before with changes being applied that
were then reverted (despite lines being stretched).
Also, even if the only bug-fixes in release branches wasn't written
down, I don't think there is any ambiguity or disagreement on following
that.
>> >
>> >Any thoughts or other suggestions on strategies to document?
>> >
> Maybe we can add some release plan/manager basics to the bylaws?
>
> """A release plan consists of:
> * a release manager
> * a proposed version number
> * a feature freeze date (bug fixes and documentation only)
> * a code freeze date (documentation only)
> * a planned rc vote date
>
> Should any of these dates be missed, the release manager is responsible for
> selecting new dates."""
A planned RC vote might be a bit aggressive. It's hard to judge whether
or not CI/RW tests will unearth some unknown bug. I like the other
items, though.
Re: [DISCUSS] Accumulo Bylaw fixes
Posted by Josh Elser <jo...@gmail.com>.
Ya, that was the general consensus we've had in off the cuff
conversations so far. It matches what we've been trying to do -- the
numbering that Accumulo has been doing just doesn't match up right now.
On 3/12/14, 6:55 PM, dlmarion@comcast.net wrote:
>
> I am going to try using the Semantic Versioning specification on my project. There is a maven plugin[2] for validation and enforcement. Reading over the specification, it seems pretty common sense and straight forward.
>
> [1] http://semver.org/
> [2] https://github.com/jeluard/semantic-versioning
>
>
> ----Original Message-----
> From: Sean Busbey [mailto:busbey+lists@cloudera.com]
> Sent: Wednesday, March 12, 2014 12:20 PM
> To: dev@accumulo apache. org
> Subject: Re: [DISCUSS] Accumulo Bylaw fixes
>
> We already have guidelines on the distinction between major and minor releases[1].
>
> I agree that we would do better to have more rigorous definitions around compatibility on both. That's a discussion I've been meaning to start, but I wanted to wait until people weren't busy with 1.6.0.
>
> It sounds like we'd be better off starting earlier, but I don't know that we need that to establish that we want release managers. We can just rely on the current weak definition for major/minor.
>
>
> [1]: http://accumulo.apache.org/governance/releasing.html
>
>
> On Wed, Mar 12, 2014 at 11:15 AM, Christopher <ct...@apache.org> wrote:
>
>> Before we establish either bylaws or guidelines which distinguish
>> between "major" and "minor" releases, I think we need to establish
>> release versioning standards first. Perhaps that discussion is a
>> prerequisite to this one? Personally, I think the results of that
>> discussion would make an excellent first amendment to the bylaws.
>>
>> --
>> Christopher L Tubbs II
>> http://gravatar.com/ctubbsii
>>
>>
>> On Wed, Mar 12, 2014 at 12:09 PM, Mike Drob <ma...@cloudera.com> wrote:
>>> Inline.
>>>
>>> On Wed, Mar 12, 2014 at 10:50 AM, Billie Rinaldi
>>> <bi...@gmail.com>wrote:
>>>
>>>> I disagree with Mike on point 4. This is not a matter of people
>>>> not
>> having
>>>> authority, and I don't see a lack of release plans / managers as
>>>> the problem behind our major releases not occurring as often as we'd like.
>> I
>>>> wouldn't be opposed to adding a release plan / manager vote as an
>> optional
>>>> step that can be taken when preparing for a release (perhaps a
>>>> strongly encouraged or even required step when it's a major release).
>>>
>>>
>>> In theory, I think this makes sense. Major releases are important
>>> enough and difficult enough that I'd really like to require a release manager.
>> In
>>> practice our minors tend to be pretty significant minors that still
>> require
>>> a significant amount of care and preparation, so I think release
>>> managers will still be useful.
>>>
>>> I also think
>>>> we should consider making the vote lazy consensus, falling back to
>> majority
>>>> approval if a -1 is received.
>>>>
>>> +0. I think shows stronger support if actually voted on up front,
>>> +but
>> this
>>> is not a deal breaker for me. Our current process is close to this
>> already.
>>>
>>>>
>>>> However, adding this step will not solve our release woes. Perhaps
>>>> something that might help would be to develop a set of suggested
>> guidelines
>>>> to follow or strategies to take when working towards the final
>>>> stages
>> of a
>>>> release, post code freeze. At least some of these should be
>>>> responsibilities of all committers, not just a release manager.
>>>>
>>>
>>> I did not mean to suggest that this was the only thing needed to
>>> improve our process. Simply that it is an easy solution that I
>>> expect to have positive outcomes. While I agree that all committers
>>> should be held responsible for driving towards a release, different
>>> people will always have different opinions on what needs to be part of any given release.
>> What
>>> I think is trivial, you might consider a blocker, and vice versa.
>>> The incomplete feature that I think needs just a little more work,
>>> you could think is immature and should be pulled entirely.
>>> Delegating authority to
>> a
>>> release manager makes these decisions simpler, while still giving us
>>> flexibility to write the code we each want.
>>>
>>>
>>>> Some guesses for what could go on this list:
>>>> - always select a new date when a previously selected date has
>>>> passed
>>>>
>>> Who is responsible for this? If dates are chosen by fiat, then they
>> quickly
>>> become meaningless. This actually sounds like a great argument _for_
>>> a release manager.
>>>
>>>
>>>> - initiate discussion of remaining tickets / tasks regularly (every
>> week?)
>>>>
>>> This can be a very daunting task.
>>>
>>>
>>>> - once a .0-SNAPSHOT branch has been created, every committer
>>>> should
>> follow
>>>> some specified procedure before committing changes to it (I don't
>>>> mean a voting procedure, more like soul-searching -- or perhaps a
>>>> simple
>>>> flowchart: Are you committing this change against a blocker or
>>>> documentation-only ticket? No => Don't commit or merge it to this
>> branch).
>>>>
>>> Soul searching is a very fuzzy concept that I am not comfortable
>>> with for being used to drive releases. We've had an implicit (read:
>>> unwritten) policy that only bug fixes can go into release branches,
>>> but many developers (myself included) have stretched both the
>>> definition of bug
>> and
>>> the definition of fix. I'm completely on board with always making
>>> code better, but it's also good to draw a line in the sand somewhere
>>> and actually make releases.
>>>
>>>>
>>>> Any thoughts or other suggestions on strategies to document?
>>>>
>>> Maybe we can add some release plan/manager basics to the bylaws?
>>>
>>> """A release plan consists of:
>>> * a release manager
>>> * a proposed version number
>>> * a feature freeze date (bug fixes and documentation only)
>>> * a code freeze date (documentation only)
>>> * a planned rc vote date
>>>
>>> Should any of these dates be missed, the release manager is
>>> responsible
>> for
>>> selecting new dates."""
>>>
>>>>
>>>>
>>>>
>>>> On Tue, Mar 11, 2014 at 1:20 PM, Sean Busbey
>>>> <busbey+lists@cloudera.com
>>>>> wrote:
>>>>
>>>>> Moving this over to its own DISCUSS thread so we can keep the
>>>>> VOTE
>> easier
>>>>> to follow.
>>>>>
>>>>> wrt #4, I'm with Mike on this. One of our big problems, as a
>> community,
>>>> is
>>>>> lack of steady release cadence. Even once we decide on a feature
>> freeze,
>>>> we
>>>>> don't have enough rigor in driving to release. For example, 1.6.0
>>>>> hit feature freeze 4.5 months ago[1]. I think John is doing fine
>>>>> given the circumstances, but without a date to drive towards it's
>>>>> hard to
>> justify
>>>>> throwing stuff off the raft.
>>>>>
>>>>> Since we'll presumably be updating the bylaws for the next vote,
>>>>> I'd
>> like
>>>>> to see a definition for the Release Manager role since we
>>>>> reference
>> it.
>>>>>
>>>>> [1]: http://s.apache.org/accumulo_1.6.0_feature_freeze_vote
>>>>>
>>>>> -Sean
>>>>>
>>>>> On Tue, Mar 11, 2014 at 1:17 PM, Mike Drob <ma...@cloudera.com>
>> wrote:
>>>>>
>>>>>> 1) Agree w/ Bill.
>>>>>>
>>>>>> 2) Agree w/ Bill.
>>>>>>
>>>>>> 3) In my understanding, codebase includes the site svn, the
>>>>>> primary
>> git
>>>>>> repository, and all contrib repositories. Adoption of a new
>>>>>> codebase generally refers to the creation of a new contrib repository.
>> However,
>>>> I
>>>>>> could see it also expanded to cover things like re-doing the
>>>>>> entire
>>>> site
>>>>>> look and feel, or merging a contrib project into the primary
>> codebase.
>>>>>> Christopher, do you have any proposed verbiage that you would
>>>>>> like
>> to
>>>> see
>>>>>> specifically?
>>>>>>
>>>>>> 4) I very much disagree, Christopher. Having a dedicated
>>>>>> release
>>>> manager
>>>>> is
>>>>>> critical to having a release occur in a timely manner. Further,
>>>>>> the community needs to be able to make hard decisions, like
>>>>>> setting a
>>>> feature
>>>>>> or code freeze date, or pulling incomplete work out of a branch.
>> Right
>>>>> now,
>>>>>> we have release managers in name only, and I would love to see
>>>>>> us
>> give
>>>>> them
>>>>>> more authority on performing the release - right now we have a
>> steady
>>>>>> stream of small changes that developers feel should be exempt
>>>>>> from
>> the
>>>>>> freeze, something I'm guilty of myself as well. I see the lack
>>>>>> of a formalized release plan as one reason for why releases
>>>>>> tend to drag
>> on
>>>>> for
>>>>>> far too long.
>>>>>>
>>>>>> In short, if we don't have a release manager pushing for them,
>>>>>> then releases just won't happen. It's a gruelling task, and we
>>>>>> need to
>> have
>>>>>> procedure to bless somebody to do it.
>>>>>>
>>>>>>
>>>>>> Mike
>>>>>>
>>>>>>
>>>>>> On Mon, Mar 10, 2014 at 11:03 PM, Bill Havanki <
>>>>> bhavanki@clouderagovt.com
>>>>>>> wrote:
>>>>>>
>>>>>>> My sense from the conversations leading up to the vote:
>>>>>>>
>>>>>>> 1) I believe the list is comprehensive, in that no other
>>>>>>> voting
>>>> actions
>>>>>> are
>>>>>>> contemplated. If we realize we need a new one, we can add it
>> later.
>>>>>>>
>>>>>>> 2) We determined that a committer, by ASF rules, cannot truly
>>>>>>> lose committer status [1], so no removal procedure is
>>>>>>> defined. Removal
>> of
>>>> a
>>>>>> PMC
>>>>>>> member is up to the ASF Board [2], so no procedure is defined.
>>>>>>>
>>>>>>> 3) I see no harm in adding a definition.
>>>>>>>
>>>>>>> 4) I think the "release plan" is the process for cutting a
>> release,
>>>>> while
>>>>>>> "product release" is for approving a specific RC as the release.
>> For
>>>>> me,
>>>>>> a
>>>>>>> boilerplate release plan with customizations (who is the RM,
>>>>>>> what
>>>> tests
>>>>>> are
>>>>>>> needed, time frame for freezes, etc.) would be nice to have
>>>>>>> laid
>> out.
>>>>>>>
>>>>>>> [1]
>>>>>>> http://www.apache.org/dev/committers.html#committer-set-term
>>>>>>> [2] http://www.apache.org/dev/pmc.html#pmc-removal
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Mar 10, 2014 at 5:52 PM, Christopher
>>>>>>> <ctubbsii@apache.org
>>>
>>>>>> wrote:
>>>>>>>
>>>>>>>> Since I didn't technically vote, I guess I will now:
>>>>>>>> I'm going to give it a -1, pending the resolution the
>>>>>>>> following issues, and for an opportunity to correct the
>>>>>>>> minor
>>>>> punctuation/typos.
>>>>>>>>
>>>>>>>> Specifically, I'd like these addressed before I change my vote:
>>>>>>>> 1) clarification of whether the ACTIONS list is
>>>>>>>> comprehensive
>>>>>>>> 2) clarify reinstatement in the absence of a lack of
>>>>>>>> removal
>>>>> procedures
>>>>>>>> 3) codebase defined (or at least, Adoption of New Codebase
>>>> clarified)
>>>>>>>> 4) remove "release plan" as requiring a vote (or discuss),
>> because
>>>>>>>> while it is nice to coordinate release candidates through a
>> release
>>>>>>>> manager, I'm not sure it should be strictly necessary that
>> release
>>>>>>>> candidates be planned, or limited to that release manager.
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Christopher L Tubbs II
>>>>>>>> http://gravatar.com/ctubbsii
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Mar 10, 2014 at 5:08 PM, Christopher <
>> ctubbsii@apache.org>
>>>>>>> wrote:
>>>>>>>>> ***Punctuation:
>>>>>>>>>
>>>>>>>>> PMC section:
>>>>>>>>> "PMC from a Foundation perspective is" -> "PMC, from a
>> Foundation
>>>>>>>>> perspective, is"
>>>>>>>>> "Secondly " -> "Secondly,"
>>>>>>>>> "long term" -> "long-term"
>>>>>>>>> "not coding - but to ensure" -> "not coding, but to ensure"
>>>>>>>>> "Within the ASF we worry" -> "Within the ASF, we worry"
>>>>>>>>>
>>>>>>>>> VETOES section (comma):
>>>>>>>>> "veto - merely that" -> "veto, merely that"
>>>>>>>>>
>>>>>>>>> ***Typos:
>>>>>>>>>
>>>>>>>>> APPROVALS section (typo):
>>>>>>>>> "that -1 votes" -> "than -1 votes"
>>>>>>>>>
>>>>>>>>> ***Definitions:
>>>>>>>>> I would like to see "codebase" defined. It's used
>>>>>>>>> throughout,
>> but
>>>>> is
>>>>>>>>> never clearly defined... particularly in the "Adoption of
>>>>>>>>> New Codebase" section of the ACTIONS section.
>>>>>>>>>
>>>>>>>>> ***Other:
>>>>>>>>> In the ACTIONS section, it describes reinstatement
>>>>>>>>> actions,
>> but
>>>> not
>>>>>>>>> removal actions, so it's not clear what reinstatement means.
>>>>>>>>>
>>>>>>>>> It should also be made clear that the ACTIONS section is
>>>>>>>>> not a comprehensive list of actions.
>>>>>>>>>
>>>>>>>>> I'm also not sure that the "Release plan" should require
>>>>>>>>> a
>> vote,
>>>> as
>>>>>>>>> this seems covered by the "Product release" situation.
>>>>>>>>> The
>> other
>>>>>>>>> actions seem to imply a vote is required for that action.
>>>>>>>>> Are
>> we
>>>>>>>>> saying that planning to release requires a vote? If so, I
>>>>>>>>> can
>> get
>>>>> on
>>>>>>>>> board... I just don't remember that happening in the
>>>>>>>>> past, so
>>>> this
>>>>>>>>> isn't so much a formalization of our existing practices,
>>>>>>>>> but
>> also
>>>>>>>>> establishing a new one as well. And, in this case, I'm
>>>>>>>>> not
>> sure
>>>>> it's
>>>>>>>>> one we need.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Christopher L Tubbs II
>>>>>>>>> http://gravatar.com/ctubbsii
>>>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>
RE: [DISCUSS] Accumulo Bylaw fixes
Posted by dl...@comcast.net.
I am going to try using the Semantic Versioning specification on my project. There is a maven plugin[2] for validation and enforcement. Reading over the specification, it seems pretty common sense and straight forward.
[1] http://semver.org/
[2] https://github.com/jeluard/semantic-versioning
----Original Message-----
From: Sean Busbey [mailto:busbey+lists@cloudera.com]
Sent: Wednesday, March 12, 2014 12:20 PM
To: dev@accumulo apache. org
Subject: Re: [DISCUSS] Accumulo Bylaw fixes
We already have guidelines on the distinction between major and minor releases[1].
I agree that we would do better to have more rigorous definitions around compatibility on both. That's a discussion I've been meaning to start, but I wanted to wait until people weren't busy with 1.6.0.
It sounds like we'd be better off starting earlier, but I don't know that we need that to establish that we want release managers. We can just rely on the current weak definition for major/minor.
[1]: http://accumulo.apache.org/governance/releasing.html
On Wed, Mar 12, 2014 at 11:15 AM, Christopher <ct...@apache.org> wrote:
> Before we establish either bylaws or guidelines which distinguish
> between "major" and "minor" releases, I think we need to establish
> release versioning standards first. Perhaps that discussion is a
> prerequisite to this one? Personally, I think the results of that
> discussion would make an excellent first amendment to the bylaws.
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Wed, Mar 12, 2014 at 12:09 PM, Mike Drob <ma...@cloudera.com> wrote:
> > Inline.
> >
> > On Wed, Mar 12, 2014 at 10:50 AM, Billie Rinaldi
> > <bi...@gmail.com>wrote:
> >
> >> I disagree with Mike on point 4. This is not a matter of people
> >> not
> having
> >> authority, and I don't see a lack of release plans / managers as
> >> the problem behind our major releases not occurring as often as we'd like.
> I
> >> wouldn't be opposed to adding a release plan / manager vote as an
> optional
> >> step that can be taken when preparing for a release (perhaps a
> >> strongly encouraged or even required step when it's a major release).
> >
> >
> > In theory, I think this makes sense. Major releases are important
> > enough and difficult enough that I'd really like to require a release manager.
> In
> > practice our minors tend to be pretty significant minors that still
> require
> > a significant amount of care and preparation, so I think release
> > managers will still be useful.
> >
> > I also think
> >> we should consider making the vote lazy consensus, falling back to
> majority
> >> approval if a -1 is received.
> >>
> > +0. I think shows stronger support if actually voted on up front,
> > +but
> this
> > is not a deal breaker for me. Our current process is close to this
> already.
> >
> >>
> >> However, adding this step will not solve our release woes. Perhaps
> >> something that might help would be to develop a set of suggested
> guidelines
> >> to follow or strategies to take when working towards the final
> >> stages
> of a
> >> release, post code freeze. At least some of these should be
> >> responsibilities of all committers, not just a release manager.
> >>
> >
> > I did not mean to suggest that this was the only thing needed to
> > improve our process. Simply that it is an easy solution that I
> > expect to have positive outcomes. While I agree that all committers
> > should be held responsible for driving towards a release, different
> > people will always have different opinions on what needs to be part of any given release.
> What
> > I think is trivial, you might consider a blocker, and vice versa.
> > The incomplete feature that I think needs just a little more work,
> > you could think is immature and should be pulled entirely.
> > Delegating authority to
> a
> > release manager makes these decisions simpler, while still giving us
> > flexibility to write the code we each want.
> >
> >
> >> Some guesses for what could go on this list:
> >> - always select a new date when a previously selected date has
> >> passed
> >>
> > Who is responsible for this? If dates are chosen by fiat, then they
> quickly
> > become meaningless. This actually sounds like a great argument _for_
> > a release manager.
> >
> >
> >> - initiate discussion of remaining tickets / tasks regularly (every
> week?)
> >>
> > This can be a very daunting task.
> >
> >
> >> - once a .0-SNAPSHOT branch has been created, every committer
> >> should
> follow
> >> some specified procedure before committing changes to it (I don't
> >> mean a voting procedure, more like soul-searching -- or perhaps a
> >> simple
> >> flowchart: Are you committing this change against a blocker or
> >> documentation-only ticket? No => Don't commit or merge it to this
> branch).
> >>
> > Soul searching is a very fuzzy concept that I am not comfortable
> > with for being used to drive releases. We've had an implicit (read:
> > unwritten) policy that only bug fixes can go into release branches,
> > but many developers (myself included) have stretched both the
> > definition of bug
> and
> > the definition of fix. I'm completely on board with always making
> > code better, but it's also good to draw a line in the sand somewhere
> > and actually make releases.
> >
> >>
> >> Any thoughts or other suggestions on strategies to document?
> >>
> > Maybe we can add some release plan/manager basics to the bylaws?
> >
> > """A release plan consists of:
> > * a release manager
> > * a proposed version number
> > * a feature freeze date (bug fixes and documentation only)
> > * a code freeze date (documentation only)
> > * a planned rc vote date
> >
> > Should any of these dates be missed, the release manager is
> > responsible
> for
> > selecting new dates."""
> >
> >>
> >>
> >>
> >> On Tue, Mar 11, 2014 at 1:20 PM, Sean Busbey
> >> <busbey+lists@cloudera.com
> >> >wrote:
> >>
> >> > Moving this over to its own DISCUSS thread so we can keep the
> >> > VOTE
> easier
> >> > to follow.
> >> >
> >> > wrt #4, I'm with Mike on this. One of our big problems, as a
> community,
> >> is
> >> > lack of steady release cadence. Even once we decide on a feature
> freeze,
> >> we
> >> > don't have enough rigor in driving to release. For example, 1.6.0
> >> > hit feature freeze 4.5 months ago[1]. I think John is doing fine
> >> > given the circumstances, but without a date to drive towards it's
> >> > hard to
> justify
> >> > throwing stuff off the raft.
> >> >
> >> > Since we'll presumably be updating the bylaws for the next vote,
> >> > I'd
> like
> >> > to see a definition for the Release Manager role since we
> >> > reference
> it.
> >> >
> >> > [1]: http://s.apache.org/accumulo_1.6.0_feature_freeze_vote
> >> >
> >> > -Sean
> >> >
> >> > On Tue, Mar 11, 2014 at 1:17 PM, Mike Drob <ma...@cloudera.com>
> wrote:
> >> >
> >> > > 1) Agree w/ Bill.
> >> > >
> >> > > 2) Agree w/ Bill.
> >> > >
> >> > > 3) In my understanding, codebase includes the site svn, the
> >> > > primary
> git
> >> > > repository, and all contrib repositories. Adoption of a new
> >> > > codebase generally refers to the creation of a new contrib repository.
> However,
> >> I
> >> > > could see it also expanded to cover things like re-doing the
> >> > > entire
> >> site
> >> > > look and feel, or merging a contrib project into the primary
> codebase.
> >> > > Christopher, do you have any proposed verbiage that you would
> >> > > like
> to
> >> see
> >> > > specifically?
> >> > >
> >> > > 4) I very much disagree, Christopher. Having a dedicated
> >> > > release
> >> manager
> >> > is
> >> > > critical to having a release occur in a timely manner. Further,
> >> > > the community needs to be able to make hard decisions, like
> >> > > setting a
> >> feature
> >> > > or code freeze date, or pulling incomplete work out of a branch.
> Right
> >> > now,
> >> > > we have release managers in name only, and I would love to see
> >> > > us
> give
> >> > them
> >> > > more authority on performing the release - right now we have a
> steady
> >> > > stream of small changes that developers feel should be exempt
> >> > > from
> the
> >> > > freeze, something I'm guilty of myself as well. I see the lack
> >> > > of a formalized release plan as one reason for why releases
> >> > > tend to drag
> on
> >> > for
> >> > > far too long.
> >> > >
> >> > > In short, if we don't have a release manager pushing for them,
> >> > > then releases just won't happen. It's a gruelling task, and we
> >> > > need to
> have
> >> > > procedure to bless somebody to do it.
> >> > >
> >> > >
> >> > > Mike
> >> > >
> >> > >
> >> > > On Mon, Mar 10, 2014 at 11:03 PM, Bill Havanki <
> >> > bhavanki@clouderagovt.com
> >> > > >wrote:
> >> > >
> >> > > > My sense from the conversations leading up to the vote:
> >> > > >
> >> > > > 1) I believe the list is comprehensive, in that no other
> >> > > > voting
> >> actions
> >> > > are
> >> > > > contemplated. If we realize we need a new one, we can add it
> later.
> >> > > >
> >> > > > 2) We determined that a committer, by ASF rules, cannot truly
> >> > > > lose committer status [1], so no removal procedure is
> >> > > > defined. Removal
> of
> >> a
> >> > > PMC
> >> > > > member is up to the ASF Board [2], so no procedure is defined.
> >> > > >
> >> > > > 3) I see no harm in adding a definition.
> >> > > >
> >> > > > 4) I think the "release plan" is the process for cutting a
> release,
> >> > while
> >> > > > "product release" is for approving a specific RC as the release.
> For
> >> > me,
> >> > > a
> >> > > > boilerplate release plan with customizations (who is the RM,
> >> > > > what
> >> tests
> >> > > are
> >> > > > needed, time frame for freezes, etc.) would be nice to have
> >> > > > laid
> out.
> >> > > >
> >> > > > [1]
> >> > > > http://www.apache.org/dev/committers.html#committer-set-term
> >> > > > [2] http://www.apache.org/dev/pmc.html#pmc-removal
> >> > > >
> >> > > >
> >> > > > On Mon, Mar 10, 2014 at 5:52 PM, Christopher
> >> > > > <ctubbsii@apache.org
> >
> >> > > wrote:
> >> > > >
> >> > > > > Since I didn't technically vote, I guess I will now:
> >> > > > > I'm going to give it a -1, pending the resolution the
> >> > > > > following issues, and for an opportunity to correct the
> >> > > > > minor
> >> > punctuation/typos.
> >> > > > >
> >> > > > > Specifically, I'd like these addressed before I change my vote:
> >> > > > > 1) clarification of whether the ACTIONS list is
> >> > > > > comprehensive
> >> > > > > 2) clarify reinstatement in the absence of a lack of
> >> > > > > removal
> >> > procedures
> >> > > > > 3) codebase defined (or at least, Adoption of New Codebase
> >> clarified)
> >> > > > > 4) remove "release plan" as requiring a vote (or discuss),
> because
> >> > > > > while it is nice to coordinate release candidates through a
> release
> >> > > > > manager, I'm not sure it should be strictly necessary that
> release
> >> > > > > candidates be planned, or limited to that release manager.
> >> > > > >
> >> > > > >
> >> > > > > --
> >> > > > > Christopher L Tubbs II
> >> > > > > http://gravatar.com/ctubbsii
> >> > > > >
> >> > > > >
> >> > > > > On Mon, Mar 10, 2014 at 5:08 PM, Christopher <
> ctubbsii@apache.org>
> >> > > > wrote:
> >> > > > > > ***Punctuation:
> >> > > > > >
> >> > > > > > PMC section:
> >> > > > > > "PMC from a Foundation perspective is" -> "PMC, from a
> Foundation
> >> > > > > > perspective, is"
> >> > > > > > "Secondly " -> "Secondly, "
> >> > > > > > "long term" -> "long-term"
> >> > > > > > "not coding - but to ensure" -> "not coding, but to ensure"
> >> > > > > > "Within the ASF we worry" -> "Within the ASF, we worry"
> >> > > > > >
> >> > > > > > VETOES section (comma):
> >> > > > > > "veto - merely that" -> "veto, merely that"
> >> > > > > >
> >> > > > > > ***Typos:
> >> > > > > >
> >> > > > > > APPROVALS section (typo):
> >> > > > > > "that -1 votes" -> "than -1 votes"
> >> > > > > >
> >> > > > > > ***Definitions:
> >> > > > > > I would like to see "codebase" defined. It's used
> >> > > > > > throughout,
> but
> >> > is
> >> > > > > > never clearly defined... particularly in the "Adoption of
> >> > > > > > New Codebase" section of the ACTIONS section.
> >> > > > > >
> >> > > > > > ***Other:
> >> > > > > > In the ACTIONS section, it describes reinstatement
> >> > > > > > actions,
> but
> >> not
> >> > > > > > removal actions, so it's not clear what reinstatement means.
> >> > > > > >
> >> > > > > > It should also be made clear that the ACTIONS section is
> >> > > > > > not a comprehensive list of actions.
> >> > > > > >
> >> > > > > > I'm also not sure that the "Release plan" should require
> >> > > > > > a
> vote,
> >> as
> >> > > > > > this seems covered by the "Product release" situation.
> >> > > > > > The
> other
> >> > > > > > actions seem to imply a vote is required for that action.
> >> > > > > > Are
> we
> >> > > > > > saying that planning to release requires a vote? If so, I
> >> > > > > > can
> get
> >> > on
> >> > > > > > board... I just don't remember that happening in the
> >> > > > > > past, so
> >> this
> >> > > > > > isn't so much a formalization of our existing practices,
> >> > > > > > but
> also
> >> > > > > > establishing a new one as well. And, in this case, I'm
> >> > > > > > not
> sure
> >> > it's
> >> > > > > > one we need.
> >> > > > > >
> >> > > > > > --
> >> > > > > > Christopher L Tubbs II
> >> > > > > > http://gravatar.com/ctubbsii
> >> > > > > >
> >> > >
> >> >
> >>
>
Re: [DISCUSS] Accumulo Bylaw fixes
Posted by Sean Busbey <bu...@cloudera.com>.
We already have guidelines on the distinction between major and minor
releases[1].
I agree that we would do better to have more rigorous definitions around
compatibility on both. That's a discussion I've been meaning to start, but
I wanted to wait until people weren't busy with 1.6.0.
It sounds like we'd be better off starting earlier, but I don't know that
we need that to establish that we want release managers. We can just rely
on the current weak definition for major/minor.
[1]: http://accumulo.apache.org/governance/releasing.html
On Wed, Mar 12, 2014 at 11:15 AM, Christopher <ct...@apache.org> wrote:
> Before we establish either bylaws or guidelines which distinguish
> between "major" and "minor" releases, I think we need to establish
> release versioning standards first. Perhaps that discussion is a
> prerequisite to this one? Personally, I think the results of that
> discussion would make an excellent first amendment to the bylaws.
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Wed, Mar 12, 2014 at 12:09 PM, Mike Drob <ma...@cloudera.com> wrote:
> > Inline.
> >
> > On Wed, Mar 12, 2014 at 10:50 AM, Billie Rinaldi
> > <bi...@gmail.com>wrote:
> >
> >> I disagree with Mike on point 4. This is not a matter of people not
> having
> >> authority, and I don't see a lack of release plans / managers as the
> >> problem behind our major releases not occurring as often as we'd like.
> I
> >> wouldn't be opposed to adding a release plan / manager vote as an
> optional
> >> step that can be taken when preparing for a release (perhaps a strongly
> >> encouraged or even required step when it's a major release).
> >
> >
> > In theory, I think this makes sense. Major releases are important enough
> > and difficult enough that I'd really like to require a release manager.
> In
> > practice our minors tend to be pretty significant minors that still
> require
> > a significant amount of care and preparation, so I think release managers
> > will still be useful.
> >
> > I also think
> >> we should consider making the vote lazy consensus, falling back to
> majority
> >> approval if a -1 is received.
> >>
> > +0. I think shows stronger support if actually voted on up front, but
> this
> > is not a deal breaker for me. Our current process is close to this
> already.
> >
> >>
> >> However, adding this step will not solve our release woes. Perhaps
> >> something that might help would be to develop a set of suggested
> guidelines
> >> to follow or strategies to take when working towards the final stages
> of a
> >> release, post code freeze. At least some of these should be
> >> responsibilities of all committers, not just a release manager.
> >>
> >
> > I did not mean to suggest that this was the only thing needed to improve
> > our process. Simply that it is an easy solution that I expect to have
> > positive outcomes. While I agree that all committers should be held
> > responsible for driving towards a release, different people will always
> > have different opinions on what needs to be part of any given release.
> What
> > I think is trivial, you might consider a blocker, and vice versa. The
> > incomplete feature that I think needs just a little more work, you could
> > think is immature and should be pulled entirely. Delegating authority to
> a
> > release manager makes these decisions simpler, while still giving us
> > flexibility to write the code we each want.
> >
> >
> >> Some guesses for what could go on this list:
> >> - always select a new date when a previously selected date has passed
> >>
> > Who is responsible for this? If dates are chosen by fiat, then they
> quickly
> > become meaningless. This actually sounds like a great argument _for_ a
> > release manager.
> >
> >
> >> - initiate discussion of remaining tickets / tasks regularly (every
> week?)
> >>
> > This can be a very daunting task.
> >
> >
> >> - once a .0-SNAPSHOT branch has been created, every committer should
> follow
> >> some specified procedure before committing changes to it (I don't mean a
> >> voting procedure, more like soul-searching -- or perhaps a simple
> >> flowchart: Are you committing this change against a blocker or
> >> documentation-only ticket? No => Don't commit or merge it to this
> branch).
> >>
> > Soul searching is a very fuzzy concept that I am not comfortable with for
> > being used to drive releases. We've had an implicit (read: unwritten)
> > policy that only bug fixes can go into release branches, but many
> > developers (myself included) have stretched both the definition of bug
> and
> > the definition of fix. I'm completely on board with always making code
> > better, but it's also good to draw a line in the sand somewhere and
> > actually make releases.
> >
> >>
> >> Any thoughts or other suggestions on strategies to document?
> >>
> > Maybe we can add some release plan/manager basics to the bylaws?
> >
> > """A release plan consists of:
> > * a release manager
> > * a proposed version number
> > * a feature freeze date (bug fixes and documentation only)
> > * a code freeze date (documentation only)
> > * a planned rc vote date
> >
> > Should any of these dates be missed, the release manager is responsible
> for
> > selecting new dates."""
> >
> >>
> >>
> >>
> >> On Tue, Mar 11, 2014 at 1:20 PM, Sean Busbey <busbey+lists@cloudera.com
> >> >wrote:
> >>
> >> > Moving this over to its own DISCUSS thread so we can keep the VOTE
> easier
> >> > to follow.
> >> >
> >> > wrt #4, I'm with Mike on this. One of our big problems, as a
> community,
> >> is
> >> > lack of steady release cadence. Even once we decide on a feature
> freeze,
> >> we
> >> > don't have enough rigor in driving to release. For example, 1.6.0 hit
> >> > feature freeze 4.5 months ago[1]. I think John is doing fine given the
> >> > circumstances, but without a date to drive towards it's hard to
> justify
> >> > throwing stuff off the raft.
> >> >
> >> > Since we'll presumably be updating the bylaws for the next vote, I'd
> like
> >> > to see a definition for the Release Manager role since we reference
> it.
> >> >
> >> > [1]: http://s.apache.org/accumulo_1.6.0_feature_freeze_vote
> >> >
> >> > -Sean
> >> >
> >> > On Tue, Mar 11, 2014 at 1:17 PM, Mike Drob <ma...@cloudera.com>
> wrote:
> >> >
> >> > > 1) Agree w/ Bill.
> >> > >
> >> > > 2) Agree w/ Bill.
> >> > >
> >> > > 3) In my understanding, codebase includes the site svn, the primary
> git
> >> > > repository, and all contrib repositories. Adoption of a new codebase
> >> > > generally refers to the creation of a new contrib repository.
> However,
> >> I
> >> > > could see it also expanded to cover things like re-doing the entire
> >> site
> >> > > look and feel, or merging a contrib project into the primary
> codebase.
> >> > > Christopher, do you have any proposed verbiage that you would like
> to
> >> see
> >> > > specifically?
> >> > >
> >> > > 4) I very much disagree, Christopher. Having a dedicated release
> >> manager
> >> > is
> >> > > critical to having a release occur in a timely manner. Further, the
> >> > > community needs to be able to make hard decisions, like setting a
> >> feature
> >> > > or code freeze date, or pulling incomplete work out of a branch.
> Right
> >> > now,
> >> > > we have release managers in name only, and I would love to see us
> give
> >> > them
> >> > > more authority on performing the release - right now we have a
> steady
> >> > > stream of small changes that developers feel should be exempt from
> the
> >> > > freeze, something I'm guilty of myself as well. I see the lack of a
> >> > > formalized release plan as one reason for why releases tend to drag
> on
> >> > for
> >> > > far too long.
> >> > >
> >> > > In short, if we don't have a release manager pushing for them, then
> >> > > releases just won't happen. It's a gruelling task, and we need to
> have
> >> > > procedure to bless somebody to do it.
> >> > >
> >> > >
> >> > > Mike
> >> > >
> >> > >
> >> > > On Mon, Mar 10, 2014 at 11:03 PM, Bill Havanki <
> >> > bhavanki@clouderagovt.com
> >> > > >wrote:
> >> > >
> >> > > > My sense from the conversations leading up to the vote:
> >> > > >
> >> > > > 1) I believe the list is comprehensive, in that no other voting
> >> actions
> >> > > are
> >> > > > contemplated. If we realize we need a new one, we can add it
> later.
> >> > > >
> >> > > > 2) We determined that a committer, by ASF rules, cannot truly lose
> >> > > > committer status [1], so no removal procedure is defined. Removal
> of
> >> a
> >> > > PMC
> >> > > > member is up to the ASF Board [2], so no procedure is defined.
> >> > > >
> >> > > > 3) I see no harm in adding a definition.
> >> > > >
> >> > > > 4) I think the "release plan" is the process for cutting a
> release,
> >> > while
> >> > > > "product release" is for approving a specific RC as the release.
> For
> >> > me,
> >> > > a
> >> > > > boilerplate release plan with customizations (who is the RM, what
> >> tests
> >> > > are
> >> > > > needed, time frame for freezes, etc.) would be nice to have laid
> out.
> >> > > >
> >> > > > [1] http://www.apache.org/dev/committers.html#committer-set-term
> >> > > > [2] http://www.apache.org/dev/pmc.html#pmc-removal
> >> > > >
> >> > > >
> >> > > > On Mon, Mar 10, 2014 at 5:52 PM, Christopher <ctubbsii@apache.org
> >
> >> > > wrote:
> >> > > >
> >> > > > > Since I didn't technically vote, I guess I will now:
> >> > > > > I'm going to give it a -1, pending the resolution the following
> >> > > > > issues, and for an opportunity to correct the minor
> >> > punctuation/typos.
> >> > > > >
> >> > > > > Specifically, I'd like these addressed before I change my vote:
> >> > > > > 1) clarification of whether the ACTIONS list is comprehensive
> >> > > > > 2) clarify reinstatement in the absence of a lack of removal
> >> > procedures
> >> > > > > 3) codebase defined (or at least, Adoption of New Codebase
> >> clarified)
> >> > > > > 4) remove "release plan" as requiring a vote (or discuss),
> because
> >> > > > > while it is nice to coordinate release candidates through a
> release
> >> > > > > manager, I'm not sure it should be strictly necessary that
> release
> >> > > > > candidates be planned, or limited to that release manager.
> >> > > > >
> >> > > > >
> >> > > > > --
> >> > > > > Christopher L Tubbs II
> >> > > > > http://gravatar.com/ctubbsii
> >> > > > >
> >> > > > >
> >> > > > > On Mon, Mar 10, 2014 at 5:08 PM, Christopher <
> ctubbsii@apache.org>
> >> > > > wrote:
> >> > > > > > ***Punctuation:
> >> > > > > >
> >> > > > > > PMC section:
> >> > > > > > "PMC from a Foundation perspective is" -> "PMC, from a
> Foundation
> >> > > > > > perspective, is"
> >> > > > > > "Secondly " -> "Secondly, "
> >> > > > > > "long term" -> "long-term"
> >> > > > > > "not coding - but to ensure" -> "not coding, but to ensure"
> >> > > > > > "Within the ASF we worry" -> "Within the ASF, we worry"
> >> > > > > >
> >> > > > > > VETOES section (comma):
> >> > > > > > "veto - merely that" -> "veto, merely that"
> >> > > > > >
> >> > > > > > ***Typos:
> >> > > > > >
> >> > > > > > APPROVALS section (typo):
> >> > > > > > "that -1 votes" -> "than -1 votes"
> >> > > > > >
> >> > > > > > ***Definitions:
> >> > > > > > I would like to see "codebase" defined. It's used throughout,
> but
> >> > is
> >> > > > > > never clearly defined... particularly in the "Adoption of New
> >> > > > > > Codebase" section of the ACTIONS section.
> >> > > > > >
> >> > > > > > ***Other:
> >> > > > > > In the ACTIONS section, it describes reinstatement actions,
> but
> >> not
> >> > > > > > removal actions, so it's not clear what reinstatement means.
> >> > > > > >
> >> > > > > > It should also be made clear that the ACTIONS section is not a
> >> > > > > > comprehensive list of actions.
> >> > > > > >
> >> > > > > > I'm also not sure that the "Release plan" should require a
> vote,
> >> as
> >> > > > > > this seems covered by the "Product release" situation. The
> other
> >> > > > > > actions seem to imply a vote is required for that action. Are
> we
> >> > > > > > saying that planning to release requires a vote? If so, I can
> get
> >> > on
> >> > > > > > board... I just don't remember that happening in the past, so
> >> this
> >> > > > > > isn't so much a formalization of our existing practices, but
> also
> >> > > > > > establishing a new one as well. And, in this case, I'm not
> sure
> >> > it's
> >> > > > > > one we need.
> >> > > > > >
> >> > > > > > --
> >> > > > > > Christopher L Tubbs II
> >> > > > > > http://gravatar.com/ctubbsii
> >> > > > > >
> >> > >
> >> >
> >>
>
Re: [DISCUSS] Accumulo Bylaw fixes
Posted by Christopher <ct...@apache.org>.
Before we establish either bylaws or guidelines which distinguish
between "major" and "minor" releases, I think we need to establish
release versioning standards first. Perhaps that discussion is a
prerequisite to this one? Personally, I think the results of that
discussion would make an excellent first amendment to the bylaws.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Wed, Mar 12, 2014 at 12:09 PM, Mike Drob <ma...@cloudera.com> wrote:
> Inline.
>
> On Wed, Mar 12, 2014 at 10:50 AM, Billie Rinaldi
> <bi...@gmail.com>wrote:
>
>> I disagree with Mike on point 4. This is not a matter of people not having
>> authority, and I don't see a lack of release plans / managers as the
>> problem behind our major releases not occurring as often as we'd like. I
>> wouldn't be opposed to adding a release plan / manager vote as an optional
>> step that can be taken when preparing for a release (perhaps a strongly
>> encouraged or even required step when it's a major release).
>
>
> In theory, I think this makes sense. Major releases are important enough
> and difficult enough that I'd really like to require a release manager. In
> practice our minors tend to be pretty significant minors that still require
> a significant amount of care and preparation, so I think release managers
> will still be useful.
>
> I also think
>> we should consider making the vote lazy consensus, falling back to majority
>> approval if a -1 is received.
>>
> +0. I think shows stronger support if actually voted on up front, but this
> is not a deal breaker for me. Our current process is close to this already.
>
>>
>> However, adding this step will not solve our release woes. Perhaps
>> something that might help would be to develop a set of suggested guidelines
>> to follow or strategies to take when working towards the final stages of a
>> release, post code freeze. At least some of these should be
>> responsibilities of all committers, not just a release manager.
>>
>
> I did not mean to suggest that this was the only thing needed to improve
> our process. Simply that it is an easy solution that I expect to have
> positive outcomes. While I agree that all committers should be held
> responsible for driving towards a release, different people will always
> have different opinions on what needs to be part of any given release. What
> I think is trivial, you might consider a blocker, and vice versa. The
> incomplete feature that I think needs just a little more work, you could
> think is immature and should be pulled entirely. Delegating authority to a
> release manager makes these decisions simpler, while still giving us
> flexibility to write the code we each want.
>
>
>> Some guesses for what could go on this list:
>> - always select a new date when a previously selected date has passed
>>
> Who is responsible for this? If dates are chosen by fiat, then they quickly
> become meaningless. This actually sounds like a great argument _for_ a
> release manager.
>
>
>> - initiate discussion of remaining tickets / tasks regularly (every week?)
>>
> This can be a very daunting task.
>
>
>> - once a .0-SNAPSHOT branch has been created, every committer should follow
>> some specified procedure before committing changes to it (I don't mean a
>> voting procedure, more like soul-searching -- or perhaps a simple
>> flowchart: Are you committing this change against a blocker or
>> documentation-only ticket? No => Don't commit or merge it to this branch).
>>
> Soul searching is a very fuzzy concept that I am not comfortable with for
> being used to drive releases. We've had an implicit (read: unwritten)
> policy that only bug fixes can go into release branches, but many
> developers (myself included) have stretched both the definition of bug and
> the definition of fix. I'm completely on board with always making code
> better, but it's also good to draw a line in the sand somewhere and
> actually make releases.
>
>>
>> Any thoughts or other suggestions on strategies to document?
>>
> Maybe we can add some release plan/manager basics to the bylaws?
>
> """A release plan consists of:
> * a release manager
> * a proposed version number
> * a feature freeze date (bug fixes and documentation only)
> * a code freeze date (documentation only)
> * a planned rc vote date
>
> Should any of these dates be missed, the release manager is responsible for
> selecting new dates."""
>
>>
>>
>>
>> On Tue, Mar 11, 2014 at 1:20 PM, Sean Busbey <busbey+lists@cloudera.com
>> >wrote:
>>
>> > Moving this over to its own DISCUSS thread so we can keep the VOTE easier
>> > to follow.
>> >
>> > wrt #4, I'm with Mike on this. One of our big problems, as a community,
>> is
>> > lack of steady release cadence. Even once we decide on a feature freeze,
>> we
>> > don't have enough rigor in driving to release. For example, 1.6.0 hit
>> > feature freeze 4.5 months ago[1]. I think John is doing fine given the
>> > circumstances, but without a date to drive towards it's hard to justify
>> > throwing stuff off the raft.
>> >
>> > Since we'll presumably be updating the bylaws for the next vote, I'd like
>> > to see a definition for the Release Manager role since we reference it.
>> >
>> > [1]: http://s.apache.org/accumulo_1.6.0_feature_freeze_vote
>> >
>> > -Sean
>> >
>> > On Tue, Mar 11, 2014 at 1:17 PM, Mike Drob <ma...@cloudera.com> wrote:
>> >
>> > > 1) Agree w/ Bill.
>> > >
>> > > 2) Agree w/ Bill.
>> > >
>> > > 3) In my understanding, codebase includes the site svn, the primary git
>> > > repository, and all contrib repositories. Adoption of a new codebase
>> > > generally refers to the creation of a new contrib repository. However,
>> I
>> > > could see it also expanded to cover things like re-doing the entire
>> site
>> > > look and feel, or merging a contrib project into the primary codebase.
>> > > Christopher, do you have any proposed verbiage that you would like to
>> see
>> > > specifically?
>> > >
>> > > 4) I very much disagree, Christopher. Having a dedicated release
>> manager
>> > is
>> > > critical to having a release occur in a timely manner. Further, the
>> > > community needs to be able to make hard decisions, like setting a
>> feature
>> > > or code freeze date, or pulling incomplete work out of a branch. Right
>> > now,
>> > > we have release managers in name only, and I would love to see us give
>> > them
>> > > more authority on performing the release - right now we have a steady
>> > > stream of small changes that developers feel should be exempt from the
>> > > freeze, something I'm guilty of myself as well. I see the lack of a
>> > > formalized release plan as one reason for why releases tend to drag on
>> > for
>> > > far too long.
>> > >
>> > > In short, if we don't have a release manager pushing for them, then
>> > > releases just won't happen. It's a gruelling task, and we need to have
>> > > procedure to bless somebody to do it.
>> > >
>> > >
>> > > Mike
>> > >
>> > >
>> > > On Mon, Mar 10, 2014 at 11:03 PM, Bill Havanki <
>> > bhavanki@clouderagovt.com
>> > > >wrote:
>> > >
>> > > > My sense from the conversations leading up to the vote:
>> > > >
>> > > > 1) I believe the list is comprehensive, in that no other voting
>> actions
>> > > are
>> > > > contemplated. If we realize we need a new one, we can add it later.
>> > > >
>> > > > 2) We determined that a committer, by ASF rules, cannot truly lose
>> > > > committer status [1], so no removal procedure is defined. Removal of
>> a
>> > > PMC
>> > > > member is up to the ASF Board [2], so no procedure is defined.
>> > > >
>> > > > 3) I see no harm in adding a definition.
>> > > >
>> > > > 4) I think the "release plan" is the process for cutting a release,
>> > while
>> > > > "product release" is for approving a specific RC as the release. For
>> > me,
>> > > a
>> > > > boilerplate release plan with customizations (who is the RM, what
>> tests
>> > > are
>> > > > needed, time frame for freezes, etc.) would be nice to have laid out.
>> > > >
>> > > > [1] http://www.apache.org/dev/committers.html#committer-set-term
>> > > > [2] http://www.apache.org/dev/pmc.html#pmc-removal
>> > > >
>> > > >
>> > > > On Mon, Mar 10, 2014 at 5:52 PM, Christopher <ct...@apache.org>
>> > > wrote:
>> > > >
>> > > > > Since I didn't technically vote, I guess I will now:
>> > > > > I'm going to give it a -1, pending the resolution the following
>> > > > > issues, and for an opportunity to correct the minor
>> > punctuation/typos.
>> > > > >
>> > > > > Specifically, I'd like these addressed before I change my vote:
>> > > > > 1) clarification of whether the ACTIONS list is comprehensive
>> > > > > 2) clarify reinstatement in the absence of a lack of removal
>> > procedures
>> > > > > 3) codebase defined (or at least, Adoption of New Codebase
>> clarified)
>> > > > > 4) remove "release plan" as requiring a vote (or discuss), because
>> > > > > while it is nice to coordinate release candidates through a release
>> > > > > manager, I'm not sure it should be strictly necessary that release
>> > > > > candidates be planned, or limited to that release manager.
>> > > > >
>> > > > >
>> > > > > --
>> > > > > Christopher L Tubbs II
>> > > > > http://gravatar.com/ctubbsii
>> > > > >
>> > > > >
>> > > > > On Mon, Mar 10, 2014 at 5:08 PM, Christopher <ct...@apache.org>
>> > > > wrote:
>> > > > > > ***Punctuation:
>> > > > > >
>> > > > > > PMC section:
>> > > > > > "PMC from a Foundation perspective is" -> "PMC, from a Foundation
>> > > > > > perspective, is"
>> > > > > > "Secondly " -> "Secondly, "
>> > > > > > "long term" -> "long-term"
>> > > > > > "not coding - but to ensure" -> "not coding, but to ensure"
>> > > > > > "Within the ASF we worry" -> "Within the ASF, we worry"
>> > > > > >
>> > > > > > VETOES section (comma):
>> > > > > > "veto - merely that" -> "veto, merely that"
>> > > > > >
>> > > > > > ***Typos:
>> > > > > >
>> > > > > > APPROVALS section (typo):
>> > > > > > "that -1 votes" -> "than -1 votes"
>> > > > > >
>> > > > > > ***Definitions:
>> > > > > > I would like to see "codebase" defined. It's used throughout, but
>> > is
>> > > > > > never clearly defined... particularly in the "Adoption of New
>> > > > > > Codebase" section of the ACTIONS section.
>> > > > > >
>> > > > > > ***Other:
>> > > > > > In the ACTIONS section, it describes reinstatement actions, but
>> not
>> > > > > > removal actions, so it's not clear what reinstatement means.
>> > > > > >
>> > > > > > It should also be made clear that the ACTIONS section is not a
>> > > > > > comprehensive list of actions.
>> > > > > >
>> > > > > > I'm also not sure that the "Release plan" should require a vote,
>> as
>> > > > > > this seems covered by the "Product release" situation. The other
>> > > > > > actions seem to imply a vote is required for that action. Are we
>> > > > > > saying that planning to release requires a vote? If so, I can get
>> > on
>> > > > > > board... I just don't remember that happening in the past, so
>> this
>> > > > > > isn't so much a formalization of our existing practices, but also
>> > > > > > establishing a new one as well. And, in this case, I'm not sure
>> > it's
>> > > > > > one we need.
>> > > > > >
>> > > > > > --
>> > > > > > Christopher L Tubbs II
>> > > > > > http://gravatar.com/ctubbsii
>> > > > > >
>> > >
>> >
>>
Re: [DISCUSS] Accumulo Bylaw fixes
Posted by Mike Drob <ma...@cloudera.com>.
Inline.
On Wed, Mar 12, 2014 at 10:50 AM, Billie Rinaldi
<bi...@gmail.com>wrote:
> I disagree with Mike on point 4. This is not a matter of people not having
> authority, and I don't see a lack of release plans / managers as the
> problem behind our major releases not occurring as often as we'd like. I
> wouldn't be opposed to adding a release plan / manager vote as an optional
> step that can be taken when preparing for a release (perhaps a strongly
> encouraged or even required step when it's a major release).
In theory, I think this makes sense. Major releases are important enough
and difficult enough that I'd really like to require a release manager. In
practice our minors tend to be pretty significant minors that still require
a significant amount of care and preparation, so I think release managers
will still be useful.
I also think
> we should consider making the vote lazy consensus, falling back to majority
> approval if a -1 is received.
>
+0. I think shows stronger support if actually voted on up front, but this
is not a deal breaker for me. Our current process is close to this already.
>
> However, adding this step will not solve our release woes. Perhaps
> something that might help would be to develop a set of suggested guidelines
> to follow or strategies to take when working towards the final stages of a
> release, post code freeze. At least some of these should be
> responsibilities of all committers, not just a release manager.
>
I did not mean to suggest that this was the only thing needed to improve
our process. Simply that it is an easy solution that I expect to have
positive outcomes. While I agree that all committers should be held
responsible for driving towards a release, different people will always
have different opinions on what needs to be part of any given release. What
I think is trivial, you might consider a blocker, and vice versa. The
incomplete feature that I think needs just a little more work, you could
think is immature and should be pulled entirely. Delegating authority to a
release manager makes these decisions simpler, while still giving us
flexibility to write the code we each want.
> Some guesses for what could go on this list:
> - always select a new date when a previously selected date has passed
>
Who is responsible for this? If dates are chosen by fiat, then they quickly
become meaningless. This actually sounds like a great argument _for_ a
release manager.
> - initiate discussion of remaining tickets / tasks regularly (every week?)
>
This can be a very daunting task.
> - once a .0-SNAPSHOT branch has been created, every committer should follow
> some specified procedure before committing changes to it (I don't mean a
> voting procedure, more like soul-searching -- or perhaps a simple
> flowchart: Are you committing this change against a blocker or
> documentation-only ticket? No => Don't commit or merge it to this branch).
>
Soul searching is a very fuzzy concept that I am not comfortable with for
being used to drive releases. We've had an implicit (read: unwritten)
policy that only bug fixes can go into release branches, but many
developers (myself included) have stretched both the definition of bug and
the definition of fix. I'm completely on board with always making code
better, but it's also good to draw a line in the sand somewhere and
actually make releases.
>
> Any thoughts or other suggestions on strategies to document?
>
Maybe we can add some release plan/manager basics to the bylaws?
"""A release plan consists of:
* a release manager
* a proposed version number
* a feature freeze date (bug fixes and documentation only)
* a code freeze date (documentation only)
* a planned rc vote date
Should any of these dates be missed, the release manager is responsible for
selecting new dates."""
>
>
>
> On Tue, Mar 11, 2014 at 1:20 PM, Sean Busbey <busbey+lists@cloudera.com
> >wrote:
>
> > Moving this over to its own DISCUSS thread so we can keep the VOTE easier
> > to follow.
> >
> > wrt #4, I'm with Mike on this. One of our big problems, as a community,
> is
> > lack of steady release cadence. Even once we decide on a feature freeze,
> we
> > don't have enough rigor in driving to release. For example, 1.6.0 hit
> > feature freeze 4.5 months ago[1]. I think John is doing fine given the
> > circumstances, but without a date to drive towards it's hard to justify
> > throwing stuff off the raft.
> >
> > Since we'll presumably be updating the bylaws for the next vote, I'd like
> > to see a definition for the Release Manager role since we reference it.
> >
> > [1]: http://s.apache.org/accumulo_1.6.0_feature_freeze_vote
> >
> > -Sean
> >
> > On Tue, Mar 11, 2014 at 1:17 PM, Mike Drob <ma...@cloudera.com> wrote:
> >
> > > 1) Agree w/ Bill.
> > >
> > > 2) Agree w/ Bill.
> > >
> > > 3) In my understanding, codebase includes the site svn, the primary git
> > > repository, and all contrib repositories. Adoption of a new codebase
> > > generally refers to the creation of a new contrib repository. However,
> I
> > > could see it also expanded to cover things like re-doing the entire
> site
> > > look and feel, or merging a contrib project into the primary codebase.
> > > Christopher, do you have any proposed verbiage that you would like to
> see
> > > specifically?
> > >
> > > 4) I very much disagree, Christopher. Having a dedicated release
> manager
> > is
> > > critical to having a release occur in a timely manner. Further, the
> > > community needs to be able to make hard decisions, like setting a
> feature
> > > or code freeze date, or pulling incomplete work out of a branch. Right
> > now,
> > > we have release managers in name only, and I would love to see us give
> > them
> > > more authority on performing the release - right now we have a steady
> > > stream of small changes that developers feel should be exempt from the
> > > freeze, something I'm guilty of myself as well. I see the lack of a
> > > formalized release plan as one reason for why releases tend to drag on
> > for
> > > far too long.
> > >
> > > In short, if we don't have a release manager pushing for them, then
> > > releases just won't happen. It's a gruelling task, and we need to have
> > > procedure to bless somebody to do it.
> > >
> > >
> > > Mike
> > >
> > >
> > > On Mon, Mar 10, 2014 at 11:03 PM, Bill Havanki <
> > bhavanki@clouderagovt.com
> > > >wrote:
> > >
> > > > My sense from the conversations leading up to the vote:
> > > >
> > > > 1) I believe the list is comprehensive, in that no other voting
> actions
> > > are
> > > > contemplated. If we realize we need a new one, we can add it later.
> > > >
> > > > 2) We determined that a committer, by ASF rules, cannot truly lose
> > > > committer status [1], so no removal procedure is defined. Removal of
> a
> > > PMC
> > > > member is up to the ASF Board [2], so no procedure is defined.
> > > >
> > > > 3) I see no harm in adding a definition.
> > > >
> > > > 4) I think the "release plan" is the process for cutting a release,
> > while
> > > > "product release" is for approving a specific RC as the release. For
> > me,
> > > a
> > > > boilerplate release plan with customizations (who is the RM, what
> tests
> > > are
> > > > needed, time frame for freezes, etc.) would be nice to have laid out.
> > > >
> > > > [1] http://www.apache.org/dev/committers.html#committer-set-term
> > > > [2] http://www.apache.org/dev/pmc.html#pmc-removal
> > > >
> > > >
> > > > On Mon, Mar 10, 2014 at 5:52 PM, Christopher <ct...@apache.org>
> > > wrote:
> > > >
> > > > > Since I didn't technically vote, I guess I will now:
> > > > > I'm going to give it a -1, pending the resolution the following
> > > > > issues, and for an opportunity to correct the minor
> > punctuation/typos.
> > > > >
> > > > > Specifically, I'd like these addressed before I change my vote:
> > > > > 1) clarification of whether the ACTIONS list is comprehensive
> > > > > 2) clarify reinstatement in the absence of a lack of removal
> > procedures
> > > > > 3) codebase defined (or at least, Adoption of New Codebase
> clarified)
> > > > > 4) remove "release plan" as requiring a vote (or discuss), because
> > > > > while it is nice to coordinate release candidates through a release
> > > > > manager, I'm not sure it should be strictly necessary that release
> > > > > candidates be planned, or limited to that release manager.
> > > > >
> > > > >
> > > > > --
> > > > > Christopher L Tubbs II
> > > > > http://gravatar.com/ctubbsii
> > > > >
> > > > >
> > > > > On Mon, Mar 10, 2014 at 5:08 PM, Christopher <ct...@apache.org>
> > > > wrote:
> > > > > > ***Punctuation:
> > > > > >
> > > > > > PMC section:
> > > > > > "PMC from a Foundation perspective is" -> "PMC, from a Foundation
> > > > > > perspective, is"
> > > > > > "Secondly " -> "Secondly, "
> > > > > > "long term" -> "long-term"
> > > > > > "not coding - but to ensure" -> "not coding, but to ensure"
> > > > > > "Within the ASF we worry" -> "Within the ASF, we worry"
> > > > > >
> > > > > > VETOES section (comma):
> > > > > > "veto - merely that" -> "veto, merely that"
> > > > > >
> > > > > > ***Typos:
> > > > > >
> > > > > > APPROVALS section (typo):
> > > > > > "that -1 votes" -> "than -1 votes"
> > > > > >
> > > > > > ***Definitions:
> > > > > > I would like to see "codebase" defined. It's used throughout, but
> > is
> > > > > > never clearly defined... particularly in the "Adoption of New
> > > > > > Codebase" section of the ACTIONS section.
> > > > > >
> > > > > > ***Other:
> > > > > > In the ACTIONS section, it describes reinstatement actions, but
> not
> > > > > > removal actions, so it's not clear what reinstatement means.
> > > > > >
> > > > > > It should also be made clear that the ACTIONS section is not a
> > > > > > comprehensive list of actions.
> > > > > >
> > > > > > I'm also not sure that the "Release plan" should require a vote,
> as
> > > > > > this seems covered by the "Product release" situation. The other
> > > > > > actions seem to imply a vote is required for that action. Are we
> > > > > > saying that planning to release requires a vote? If so, I can get
> > on
> > > > > > board... I just don't remember that happening in the past, so
> this
> > > > > > isn't so much a formalization of our existing practices, but also
> > > > > > establishing a new one as well. And, in this case, I'm not sure
> > it's
> > > > > > one we need.
> > > > > >
> > > > > > --
> > > > > > Christopher L Tubbs II
> > > > > > http://gravatar.com/ctubbsii
> > > > > >
> > >
> >
>
Re: [DISCUSS] Accumulo Bylaw fixes
Posted by Billie Rinaldi <bi...@gmail.com>.
I disagree with Mike on point 4. This is not a matter of people not having
authority, and I don't see a lack of release plans / managers as the
problem behind our major releases not occurring as often as we'd like. I
wouldn't be opposed to adding a release plan / manager vote as an optional
step that can be taken when preparing for a release (perhaps a strongly
encouraged or even required step when it's a major release). I also think
we should consider making the vote lazy consensus, falling back to majority
approval if a -1 is received.
However, adding this step will not solve our release woes. Perhaps
something that might help would be to develop a set of suggested guidelines
to follow or strategies to take when working towards the final stages of a
release, post code freeze. At least some of these should be
responsibilities of all committers, not just a release manager.
Some guesses for what could go on this list:
- always select a new date when a previously selected date has passed
- initiate discussion of remaining tickets / tasks regularly (every week?)
- once a .0-SNAPSHOT branch has been created, every committer should follow
some specified procedure before committing changes to it (I don't mean a
voting procedure, more like soul-searching -- or perhaps a simple
flowchart: Are you committing this change against a blocker or
documentation-only ticket? No => Don't commit or merge it to this branch).
Any thoughts or other suggestions on strategies to document?
On Tue, Mar 11, 2014 at 1:20 PM, Sean Busbey <bu...@cloudera.com>wrote:
> Moving this over to its own DISCUSS thread so we can keep the VOTE easier
> to follow.
>
> wrt #4, I'm with Mike on this. One of our big problems, as a community, is
> lack of steady release cadence. Even once we decide on a feature freeze, we
> don't have enough rigor in driving to release. For example, 1.6.0 hit
> feature freeze 4.5 months ago[1]. I think John is doing fine given the
> circumstances, but without a date to drive towards it's hard to justify
> throwing stuff off the raft.
>
> Since we'll presumably be updating the bylaws for the next vote, I'd like
> to see a definition for the Release Manager role since we reference it.
>
> [1]: http://s.apache.org/accumulo_1.6.0_feature_freeze_vote
>
> -Sean
>
> On Tue, Mar 11, 2014 at 1:17 PM, Mike Drob <ma...@cloudera.com> wrote:
>
> > 1) Agree w/ Bill.
> >
> > 2) Agree w/ Bill.
> >
> > 3) In my understanding, codebase includes the site svn, the primary git
> > repository, and all contrib repositories. Adoption of a new codebase
> > generally refers to the creation of a new contrib repository. However, I
> > could see it also expanded to cover things like re-doing the entire site
> > look and feel, or merging a contrib project into the primary codebase.
> > Christopher, do you have any proposed verbiage that you would like to see
> > specifically?
> >
> > 4) I very much disagree, Christopher. Having a dedicated release manager
> is
> > critical to having a release occur in a timely manner. Further, the
> > community needs to be able to make hard decisions, like setting a feature
> > or code freeze date, or pulling incomplete work out of a branch. Right
> now,
> > we have release managers in name only, and I would love to see us give
> them
> > more authority on performing the release - right now we have a steady
> > stream of small changes that developers feel should be exempt from the
> > freeze, something I'm guilty of myself as well. I see the lack of a
> > formalized release plan as one reason for why releases tend to drag on
> for
> > far too long.
> >
> > In short, if we don't have a release manager pushing for them, then
> > releases just won't happen. It's a gruelling task, and we need to have
> > procedure to bless somebody to do it.
> >
> >
> > Mike
> >
> >
> > On Mon, Mar 10, 2014 at 11:03 PM, Bill Havanki <
> bhavanki@clouderagovt.com
> > >wrote:
> >
> > > My sense from the conversations leading up to the vote:
> > >
> > > 1) I believe the list is comprehensive, in that no other voting actions
> > are
> > > contemplated. If we realize we need a new one, we can add it later.
> > >
> > > 2) We determined that a committer, by ASF rules, cannot truly lose
> > > committer status [1], so no removal procedure is defined. Removal of a
> > PMC
> > > member is up to the ASF Board [2], so no procedure is defined.
> > >
> > > 3) I see no harm in adding a definition.
> > >
> > > 4) I think the "release plan" is the process for cutting a release,
> while
> > > "product release" is for approving a specific RC as the release. For
> me,
> > a
> > > boilerplate release plan with customizations (who is the RM, what tests
> > are
> > > needed, time frame for freezes, etc.) would be nice to have laid out.
> > >
> > > [1] http://www.apache.org/dev/committers.html#committer-set-term
> > > [2] http://www.apache.org/dev/pmc.html#pmc-removal
> > >
> > >
> > > On Mon, Mar 10, 2014 at 5:52 PM, Christopher <ct...@apache.org>
> > wrote:
> > >
> > > > Since I didn't technically vote, I guess I will now:
> > > > I'm going to give it a -1, pending the resolution the following
> > > > issues, and for an opportunity to correct the minor
> punctuation/typos.
> > > >
> > > > Specifically, I'd like these addressed before I change my vote:
> > > > 1) clarification of whether the ACTIONS list is comprehensive
> > > > 2) clarify reinstatement in the absence of a lack of removal
> procedures
> > > > 3) codebase defined (or at least, Adoption of New Codebase clarified)
> > > > 4) remove "release plan" as requiring a vote (or discuss), because
> > > > while it is nice to coordinate release candidates through a release
> > > > manager, I'm not sure it should be strictly necessary that release
> > > > candidates be planned, or limited to that release manager.
> > > >
> > > >
> > > > --
> > > > Christopher L Tubbs II
> > > > http://gravatar.com/ctubbsii
> > > >
> > > >
> > > > On Mon, Mar 10, 2014 at 5:08 PM, Christopher <ct...@apache.org>
> > > wrote:
> > > > > ***Punctuation:
> > > > >
> > > > > PMC section:
> > > > > "PMC from a Foundation perspective is" -> "PMC, from a Foundation
> > > > > perspective, is"
> > > > > "Secondly " -> "Secondly, "
> > > > > "long term" -> "long-term"
> > > > > "not coding - but to ensure" -> "not coding, but to ensure"
> > > > > "Within the ASF we worry" -> "Within the ASF, we worry"
> > > > >
> > > > > VETOES section (comma):
> > > > > "veto - merely that" -> "veto, merely that"
> > > > >
> > > > > ***Typos:
> > > > >
> > > > > APPROVALS section (typo):
> > > > > "that -1 votes" -> "than -1 votes"
> > > > >
> > > > > ***Definitions:
> > > > > I would like to see "codebase" defined. It's used throughout, but
> is
> > > > > never clearly defined... particularly in the "Adoption of New
> > > > > Codebase" section of the ACTIONS section.
> > > > >
> > > > > ***Other:
> > > > > In the ACTIONS section, it describes reinstatement actions, but not
> > > > > removal actions, so it's not clear what reinstatement means.
> > > > >
> > > > > It should also be made clear that the ACTIONS section is not a
> > > > > comprehensive list of actions.
> > > > >
> > > > > I'm also not sure that the "Release plan" should require a vote, as
> > > > > this seems covered by the "Product release" situation. The other
> > > > > actions seem to imply a vote is required for that action. Are we
> > > > > saying that planning to release requires a vote? If so, I can get
> on
> > > > > board... I just don't remember that happening in the past, so this
> > > > > isn't so much a formalization of our existing practices, but also
> > > > > establishing a new one as well. And, in this case, I'm not sure
> it's
> > > > > one we need.
> > > > >
> > > > > --
> > > > > Christopher L Tubbs II
> > > > > http://gravatar.com/ctubbsii
> > > > >
> >
>