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 <[email protected]> wrote: > Inline. > > On Wed, Mar 12, 2014 at 10:50 AM, Billie Rinaldi > <[email protected]>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 <[email protected] >> >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 <[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 >> > > > > > >> > > >> > >>
