accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [DISCUSS] Accumulo Bylaw fixes
Date Wed, 12 Mar 2014 16:15:40 GMT
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 <madrob@cloudera.com> wrote:
> Inline.
>
> On Wed, Mar 12, 2014 at 10:50 AM, Billie Rinaldi
> <billie.rinaldi@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 <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
>> > > > > >
>> > >
>> >
>>

Mime
View raw message