accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <dlmar...@comcast.net>
Subject RE: [DISCUSS] Accumulo Bylaw fixes
Date Wed, 12 Mar 2014 22:55:20 GMT

 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 <ctubbsii@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 <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