accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <busbey+li...@cloudera.com>
Subject Re: [DISCUSS] Accumulo Bylaw fixes
Date Thu, 13 Mar 2014 16:49:27 GMT
I do like the idea of a development schedule. I think for major releases we
should setting target dates when we start, which will practically require a
development schedule of some kind.

I still think a Release Manager is needed for this, because it's
impractical to do a PMC vote every time we need to make a decision about if
e.g. a bug fix is critical enough to include or if a feature is complete
enough to pass the gate for a given release.


On Thu, Mar 13, 2014 at 11:44 AM, Christopher <ctubbsii@apache.org> wrote:

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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message