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