accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [VOTE] Accumulo Bylaws
Date Wed, 12 Mar 2014 15:45:58 GMT
1) Is the list both comprehensive and compulsory? Are these actions
ones which require a vote? If so, that should be clarified.

2) Then we should remove actions that describe reinstatement, as they
make no sense if removal is not possible.

3) Mike's language seems reasonable.

4) See forked thread for detailed discussion, but in short, I agree
with the value of having a release manager. The question is whether or
not it requires a vote, since it's a brand new thing. This is related
to #1 above. I think it's safe to say that there is not yet consensus
that this action should require a vote, so if the actions listed are
intended to indicate those actions for which a vote is required, then
we should omit this for the acceptance of the initial bylaws. I also
think that "release plan" is ill-defined here, so it's hard to make
voting to establish one mandatory. We can always add it later (and I'd
probably be in favor of doing so), pending the results of the detailed
discussions in the forked thread, but I'd hate to have that one action
hold up the initial bylaws, so I don't think it should be included in
the first version.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii


On Tue, Mar 11, 2014 at 2:17 PM, Mike Drob <madrob@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
>> > >
>> > >
>> > > On Mon, Mar 10, 2014 at 2:38 PM, Bill Havanki <
>> bhavanki@clouderagovt.com>
>> > wrote:
>> > >> I clarify my vote with it being the first +1 (I approve) :)
>> > >>
>> > >>
>> > >> On Mon, Mar 10, 2014 at 2:29 PM, Mike Drob <madrob@cloudera.com>
>> wrote:
>> > >>
>> > >>> Was pointed out an error in the vote descriptions. They should
be:
>> > >>>
>> > >>> [ ] +1 - "I approve of these proposed bylaws and accept them for
the
>> > Apache
>> > >>> Accumulo project"
>> > >>> [ ] +0 - "I neither approve nor disapprove of these bylaws, but
>> accept
>> > them
>> > >>> for the Apache Accumulo project"
>> > >>> [ ] -1 - "I do not approve of these proposed bylaws and do not
accept
>> > them
>> > >>> for the Apache Accumulo project because..."
>> > >>>
>> > >>> Obviously, everybody has a choice when they're voting. :)
>> > >>>
>> > >>>
>> > >>> On Mon, Mar 10, 2014 at 2:23 PM, Mike Drob <madrob@cloudera.com>
>> > wrote:
>> > >>>
>> > >>> > Please vote on the proposed bylaws, as available at
>> > >>> >
>> > >>>
>> >
>> https://svn.apache.org/viewvc/accumulo/site/trunk/content/bylaws.mdtext?revision=1574615&view=markup
>> > >>> >
>> > >>> > A nicer to read version is available at
>> > >>> > http://accumulo.apache.org/bylaws.html
>> > >>> >
>> > >>> > This vote will be open for 7 days, until 17 March 18:15 UTC.
>> > >>> >
>> > >>> > Upon successful completion of this vote, the first line of
the
>> > document
>> > >>> > body will be replaced with "This is version 1 of the bylaws."
>> > >>> Additionally,
>> > >>> > and a link will be added to this document on the nav-bar on
the
>> left.
>> > >>> >
>> > >>> > This vote requires majority approval to pass: at least 3 +1
votes
>> and
>> > >>> more
>> > >>> > +1 than -1's.
>> > >>> >
>> > >>> > Mike
>> > >>> >
>> > >>> > [ ] +1 - "I approve of these proposed bylaws and accept them
for
>> the
>> > >>> > Apache Accumulo project"
>> > >>> > [ ] +0 - "I neither approve nor disapprove of these bylaws,
but
>> > accept
>> > >>> > them for the Apache Accumulo project"
>> > >>> > [ ] +1 - "I do not approve of these proposed bylaws and do
not
>> accept
>> > >>> them
>> > >>> > for the Apache Accumulo project because..."
>> > >>> >
>> > >>>
>> > >>
>> > >>
>> > >>
>> > >> --
>> > >> // Bill Havanki
>> > >> // Solutions Architect, Cloudera Govt Solutions
>> > >> // 443.686.9283
>> >
>>
>>
>>
>> --
>> // Bill Havanki
>> // Solutions Architect, Cloudera Govt Solutions
>> // 443.686.9283
>>

Mime
View raw message