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 <[email protected]> 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 <[email protected] > >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 <[email protected]> > 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 <[email protected]> > > 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 > > > > >
