Discuss the Raring Release Schedule, and ongoing changes

Registered by Pete Graner on 2012-10-26

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:
milestone icon ubuntu-13.04
Started by
Colin Watson on 2012-11-15
Completed by
Colin Watson on 2012-11-15

Related branches

Sprints

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://wiki.ubuntu.com/RaringRingtail/ReleaseSchedule

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-13.04-beta-1:
[cjwatson] set up monthly/freezely milestones for raring: DONE
[cjwatson] update NewReleaseCycleProcess to correspond to new milestone scheme: DONE
[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