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 <[email protected]> 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 <[email protected]> wrote: > > On Tue, Mar 11, 2014 at 4: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. > >> > > > > 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 <[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 > >> > > > > > >> > > >> >
