+1 to proposal. On 10/14/2016 02:08 PM, Sean Myers wrote: > I think the current Y Release Cadence has proven to be untenable. > > Here's a summary of what I think about it based on our experience: > * Branching at the first build (beta 1 release) works very well, so we should > keep doing that. > * 6-week GA-to-GA dev windows are too small, so we should increase this to 9 > weeks (maybe more) > * Our betas seem to always catch a few blockers, so the timeline always slips > between beta and RC, > and might slip again between RC and GA. This is completely normal, and is > in fact why we have > Beta and RC stages, so this uncertainty should be built into the process. > * I don't know that we ever really respected the feature freeze; it seemed to > me like the knowledge > that we were cutting a beta in a week was "good enough", and there's no > need to formally freeze > development. Our three-week sprint cycles also do a good job of effectively > feature-freezing > every three weeks. > * "Resetting the clock" after each beta, and especially after each release > candidate, doesn't > seem to add stability. Instead, it seems to add frustration in the form of > release delays. The > decision to advance from Beta to RC and RC to GA should be handled > per-release, with the only > strictly enforced time restriction being that a minimum of one week should > pass before advancing > to the next phase is allowed. > > With those points in mind, the proposed changes are to release the first beta > in a time-based way, > 9 weeks after the release date of the first beta of the previous Y release. > Once a beta is released, > no release timelines are guaranteed for the progression from beta to RC to GA > beyond reasonable > minimums (currently 1 week minimum testing time for a beta, and 1 week > minimum testing time for RC). > > Scheduling from beta to beta isolates the release process from the normal > pre-release rebuilding > delays that happen as a result of fixing blocking issues, while still giving > the release schedule > predictability so folks can do reasonable planning around our release dates. > > With all that preamble, here's my proposed "Y" release schedule: > > --- > > The Y release cycle begins on the day of the previous *Beta* Y release. > > * week 0: (Y-1 Release) Previous Y release cycle begins with a Beta Release > * week 9: (Y Release) Y release cycle begins with a Beta Release > ** dev branch created for this Y Release > ** build system adapted to build from dev branch > ** master branch now tracks development for next Y release > ** beta is built from dev branch > * week 9+1?: Y release advances through Beta phase to RC as phase conditions > are met, with > a minimum time in Beta of one week. Release schedule is no longer > time-based. > * week 9+2?: Y release advances through RC phase to GA as phase conditions > are met, with > a minimum time in RC of one week. > > --- > > The phase conditions mentioned in this schedule are listed on the linked wiki > page already, > but should be more clearly defined. Along with this proposed schedule, here > are my proposed > definitions for those terms: > > Beta: All bug fixes that need to be in the release are complete. Dev believes > the release is ready. > For Y releases, verification of the new functionality begins. > Release Candidate (RC): Verification of new functionality is completed. No > new bug fixes accepted > after this point except fixes for regressions, > upgrade failures, or security. > There are no release candidates for Z releases. > Generally Available (GA): Unchanged. > Dev branch: Unchanged. > Feature Freeze: This definition should go away if feature freeze is removed > from our "Y" release schedule. > If we keep the feature freeze step in, this definition can > remain unchanged. > > This schedule is less structured that the previous iteration, but I think it > more accurately > reflects how our releases actually go. > > The 2.10.0 beta was first released August 4, which would mean that under this > schedule we would > have begun the 2.11 release process last week. That feels about right to me, > if we were staying > on a strict time-based release cadence for 2.y, but going back to a 12-week > (quarterly-ish) > schedule would probably also be reasonable. > > For reference, here's the current "Y" release cadence posted in the project > wiki[0]: > > --- > > The Y release cycle begins on the day of the previous GA Y release. > > * week 0: (Y-1) Previous Y Generally Available Release > * week 3: Feature Freeze > * week 4: Beta Y release > ** dev branch created for this Y Release > ** build system adapted to build from dev branch > ** master branch now tracks development for next Y release > ** beta is built from dev branch > * week 5: Y Release Candidate > * week 6: Generally Available Y Release > > --- > > More words here because this email doesn't have enough words... > > [0]: https://pulp.plan.io/projects/pulp/wiki/Release_Schedule > > > > _______________________________________________ > Pulp-dev mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/pulp-dev >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
