accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: [DISCUSS] Accumulo Bylaw fixes
Date Wed, 12 Mar 2014 22:57:21 GMT
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 <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