> I think it makes sense to separate the technical aspects and requirements > of a release from a list of suggestions for the release manager (and the > community) about how to get things done when leading up to a release (X > can happen, and Y are some possible ways of dealing with it).
I agree. I think of it as mechanical steps, such as how to tag a release, vs. procedural steps, like how to judge commits after feature freeze, say. > Here's a question: should the release plan contain a list of major features > intended for the release? I personally wouldn't be interested in having a feature list in the release plan. There would already be a CHANGES doc and release notes by the end, and the vote to start the release process would involve discussing which features go into it. > Should the release manager have sole responsibility for determining > whether a major feature makes it into the release if the feature isn't quite > ready, or should it require a vote? That is a good question. At least for a major release, the beginning of the release process = feature freeze. [1] I like the idea of a vote to replan, to cancel the current release process and start over. That could be useful in other scenarios, like changing a target release date. [1] http://accumulo.apache.org/governance/releasing.html - On Wed, Mar 12, 2014 at 12:47 PM, Billie Rinaldi <[email protected]>wrote: > On Wed, Mar 12, 2014 at 8:54 AM, Bill Havanki <[email protected] > >wrote: > > > The idea of "guidelines" brings to mind the Pirate Code :) > > > > https://www.youtube.com/watch?v=b6kgS_AwuH0 > > > > Release guidelines do exist [1] and your suggestions seem to me good > > additions to them. > > > I think it makes sense to separate the technical aspects and requirements > of a release from a list of suggestions for the release manager (and the > community) about how to get things done when leading up to a release (X can > happen, and Y are some possible ways of dealing with it). Maybe the things > I listed don't all fit in the latter category. > > Based on Mike's and Bill's discussions, I am +1 for requiring a release > manager and plan. I think having a release plan template is a very good > idea, and I like Mike's suggested addition of "A release plan consists of > ..." to the bylaws. We're probably going to need a "release manager > responsibilities" section at some point, but maybe not in the first draft. > > Here's a question: should the release plan contain a list of major features > intended for the release? Should the release manager have sole > responsibility for determining whether a major feature makes it into the > release if the feature isn't quite ready, or should it require a vote? > > > > There are also some procedures defined there and > > elsewhere [2] [3] [4] on how mechanically to do a release. However, I see > > nothing declaring, for example: > > > > - that the release manager does much more than package and sign the code > > and call votes on RCs > > - that we pick a date for code freeze, or even use one, and what it means > > - that we pick a target date for release > > - what a release manager is entitled to do to get the release done > > - how we ensure that required testing has happened > > - who is responsible for testing > > > > There may be agreed-upon customs for all of the above; if so, they should > > be codified, and more than just as guidelines. An actual plan gives us > > rigor. We will be consistent between releases, and have a stable baseline > > for improving over time. A plan clears up ambiguities, saying who needs > to > > do what, and what does not need to be done. It helps newbies like me > > understand what's going on. It's something we can give out as a service > to > > the community, so that users can plan ahead, and know what we promise to > do > > for them. > > > > I wouldn't expect a release plan to be more than, as I said, a > boilerplate > > with filled-in blanks: RM is this person, feature freeze then, code > freeze > > then, release by then, everything else follows the general, standard > rules. > > Then lazy consensus would be a great voting choice. > > > > Having no plan to shoot for makes all the goal dates very soft and prone > to > > delay. No one knows when we'll be done and can move on. There's no > > motivation. Overall, it doesn't make sense to me to say, "Let's not > plan." > > :) > > > > [1] http://accumulo.apache.org/governance/releasing.html > > [2] http://accumulo.apache.org/releasing.html > > [3] https://www.apache.org/dev/release-publishing.html > > [4] http://www.apache.org/dev/release.html > > > > > > 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). I also > > think > > > we should consider making the vote lazy consensus, falling back to > > majority > > > approval if a -1 is received. > > > > > > 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. > > > > > > Some guesses for what could go on this list: > > > - always select a new date when a previously selected date has passed > > > - initiate discussion of remaining tickets / tasks regularly (every > > week?) > > > - 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). > > > > > > Any thoughts or other suggestions on strategies to document? > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > // Bill Havanki > > // Solutions Architect, Cloudera Govt Solutions > > // 443.686.9283 > > > -- // Bill Havanki // Solutions Architect, Cloudera Govt Solutions // 443.686.9283
