Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAGUtCHr4GMRK-VBqdaKEh3d-4MJrRXtL+67wsXL0WHM4=D1VTg@mail.gmail.com>
References: 
 <CAGHyZ6J1+vJB_gwJuWqpvsxJWnqv7MB=wtdJOgDv-yFXktz0_Q@mail.gmail.com>
	<CAGUtCHr4GMRK-VBqdaKEh3d-4MJrRXtL+67wsXL0WHM4=D1VTg@mail.gmail.com>
Date: Thu, 13 Mar 2014 12:44:11 -0400
Message-ID: 
 <CAL5zq9ZRpoaHkiOg5M1-mpr4ScNdbiHgU7WPdRM3EKebTyrPsQ@mail.gmail.com>
Subject: Re: [DISCUSS] Accumulo Bylaw fixes
From: Christopher <ctubbsii@apache.org>
To: Accumulo Dev List <dev@accumulo.apache.org>
Content-Type: text/plain; charset=UTF-8

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