Discuss the Raring Release Schedule, and ongoing changes
This session is to review the Raring Release Schedule and discuss removing the 3 Alpha & one of the two Beta milestones.
Blueprint information
- Status:
- Complete
- Approver:
- Steve Langasek
- Priority:
- Essential
- Drafter:
- Pete Graner
- Direction:
- Approved
- Assignee:
- Pete Graner
- Definition:
- Approved
- Series goal:
- Accepted for raring
- Implementation:
- Implemented
- Milestone target:
- ubuntu-13.04
- Started by
- Colin Watson
- Completed by
- Colin Watson
Whiteboard
[Whiteboard]
What does this mean for freezes?
[Notes]
The testing behind a continually usable release means that freezes can become far less important.
How do we target work without milestones?
- People can do per-team milestones, when in a different product
- All (?) the flavours have products within launchpad, which they could use for their own milestones
- Ubuntu could do arbitrary monthly milestones (engineering managers to sort out for team), what kind of granularity would be useful.
- Targetting bugs - more useful if have monthly. Month 1-6. Is month the right granularity? End game is Beta 1, Beta 2, final - seems right.
- Workitem and Bug targetting - engineering managers decide on monthly targets likely. Monthly milestones for this cycle.
- Milestone for feature freeze, UI freeze, Kernel freeze, FinalFreeze.
- Need a place where product managers to collaborate.
- Flavours, like Edubuntu could use a daily for a preview release for testing of newly landed features, image could be preserved
We were getting useful testing from alphas
- But poorly timed for the installer bugs
- And people keep using the milestoned images long after they lose any value. (The big issues were fixed, a currently daily image would be better to use)
We were getting publicity from alphas
- We could just bless a particular daily as being "a good release to test" / an "alpha"
- And, in fact, people would just be grabbing the latest daily, if they followed the "current" symlink
Point Releases are still needed for LTS, so how does that interact with milestones. SRU processing happening earlier is time of highest interaction.
At time releasing milestone resolve manifest inconsistencies.
https:/
Alphas are left in cycle, and make it an opt in for flavor - take away semantic? Rename as alpha testing? Let product manager participate in flavors discuss - see action from prior session.
Finesse the semantic.
Final Freeze likely 2 weeks out - everything being added to be reviewed. Beta is 4 weeks out. Want -proposed to be empty. Clean up processes in Release team on difference between 0-day SRU, and the final fixes being accepted. Plus one maintenance focus on clearing queue down.
Extend time before Feature Freeze and Debian Infrastructure Freeze. Possibly depends on where we are in Debian cycle - risk of instability, little extra time to clean up after for Ubuntu integration.
Feature Freeze is 2 weeks before Beta 1 (week 20); but Release Team will now be a harder on the Freeze, and become stricter on what is let in.
Debian import Freeze from Week 10 to Week 17. Plan fully autosyncs.
Work Items
Work items for ubuntu-
[cjwatson] set up monthly/freezely milestones for raring: DONE
[cjwatson] update NewReleaseCycle
[pgraner] Schedule a PM session for Flavors and email Ubuntu Devel List: DONE
[persia] follow up with product managers of flavors to decide on dates for flavor alphas (include Nick and ubuntu-release; must be done within a week of UDS): DONE
[pgraner] Update schedule with new dates fof FF (wk 20) & Deb Import Freeze (wk 17): DONE
[pgraner] Update the schedule to reflect the new changes (keep the old milestones on but denote that are not active): DONE
Work items:
[kitterman] Write and publish script to select packages to block for partial proposed transition blocks - Needed before Alpha 2: INPROGRESS