Release Team Members meeting

Registered by Kate Stewart

Meeting of release team to do some brainstorming on things to be improved in next cycle.

Blueprint information

Kate Stewart
Kate Stewart
Ubuntu Release Team
Series goal:
Accepted for precise
Milestone target:
Started by
Kate Stewart
Completed by
Kate Stewart

Related branches



Work Items:
[kate.stewart] Document conventions of release-team for new members: POSTPONED
[kate.stewart] Escalate LP queue audit trail (#885739) and queue admin granularity (#648611 ) bugs: DONE
[kate.stewart] identify release team member to grant archive admin privileges to, to do queue manipulation for unapproved only.: POSTPONED
[adconrad] file bug for audit trail on queues (#885739): DONE
[kate.stewart] After kernel SRUs added to interlock, coordinate Lucid point release HW recertification with Ara, and then coord with Daviey: DONE
[adconrad] sign up on PrecisePangolin/ReleaseTaskSignup: DONE
[cjwatson] sign up on PrecisePangolin/ReleaseTaskSignup: DONE
[mcasadevall] sign up on PrecisePangolin/ReleaseTaskSignup: DONE
[jr] sign up on PrecisePangolin/ReleaseTaskSignup: DONE
[kate.stewart] find a location to publish expectations about SRU team: DONE
[cjwatson] Create series matching releases on the release-notes project: DONE
[kate.stewart] Garden down release-notes bugs: DONE
[kate.stewart] add convention about ReleaseNotesProject to documented conventions.: DONE
[pitti] to reannounce the policy, and SRU team needs to commit to doing it: DONE
[kate.stewart] Add UnseededUniverseFinalFreeze to release schedule and interlock: DONE


Topics to discuss:
- logging of package accepts from queue during freeze periods?
- convention to use to signal discussion prior to approval during freeze window?
- work partitioning during Precise (
- work partitioning for SRU updates ( kernel, managing availability expectations)
- brainstorm conventions to make release note generation more effective. Multiple sources to be searched - "Release Notes Project", "unfixed oneiric bugs", "deferred bugs to pangolin". serttle on tag?
- ...?

Tactical release processes

No tracking of who approves freeze exceptions, queue manipulations during milestone periods
 - LP doesn't track queue manipulations
 - Tradition was to comment on mailing list but not adhered to.
 - Commenting during review prevents double-review
 - Bad mechanisms to request rejections from other teams
 - Individual pings work best (nick highlighting at a minimum)
 - Outstanding LP bugs for finer-grained queue permissions
 - Convention: reject if there is doubt, then discuss; can accept from rejected queue
 - Expectation that release-team members are competent, able to judge their own limitations, decision making abilities
 - Conventions aren't documented for ramping up new team members
 - How do we define what "feature" requiring FFe is
 - Inherently a judgement call; lots of gray area
 - People (gaming the system and) breaking FeatureFreeze should be named and shamed
 - Not all FFes need to be formally documented with LP bug trail if risk is low, public IRC at a minimum - must be auditable in some manner.
 - Audit trail bug with LP not escalated to LP
- Queue granularity - universe archive admin.

Side discussion about problems with test builds
 - Can we require binary uploads? Only publish source once binary build?

May not have archive admin focused on universe this cycle
 - Or review queues
 - Queue review is easier than source/bin NEW review

Task signup sheet for work partitioning
 - Who is responsible for different tasks at each milestone
 - Tasks usually coordinated across multiple people, good to have someone to herd cats, supervise, and be responsible
 - Please have people sign up
 - Use as learning opportunities?
 - Archive management for point release
   - Tell ubuntu-sru to stop accepting
   - Make sure SRUs are verified
   - d-i gets rebuilt
   - test images get built
   - Cat herding up to just before release
   - Not all tasks require corporate access

Managing SRU availability expectations:
 - Now have geographic distribution (RAOF in AU, clint-fewbar in US, pitti in EU)
 - Ask SRU questions, make decisions on bugs (want audit trail)
 - Would be nice for kernel to be able to copy from PPA to proposed and manage their own flow without needing ubuntu-sru (copy-packages - general upload won't work).
 - Have kernel-overrides mechanisms for fixing components (keep using for devel release)
 - Shouldn't be problem with copy from PPAs - should be in main to begin with
 - Should make sure we have LP bug (when we have audit trail)
 - sru-release times out on kernels (and other large SRUs)

Making generation of release notes more effective?
 - release-notes project used some
 - bug links and content not great
 - what conventions for adding bugs to release notes?
 - release-notes project has stale content
   - need to prune project after release?
 - need to figure out from bug what release it's against
 - can add series to projects, requires maintaining parallel structure
 - not doing enough gardening - should get it down
 - "Fix Committed": Somebody wordsmithed text
   " Fix Released": In the notes

Oneiric SRU queues: lots of packages without MREs, don't fix high-priority bugs
 - Have trivial/safe patches clause
 - Early release much worse
 - Lots of people using -proposed after release; catches more people
 - Desktop stays on stable release to test SRUs, GNOME point release
 - Lots of forward pocket-copies
   - Those aren't expected for non-0-days
 - 0-day SRUs are different
 - Don't have good criteria for 0-days
 - People uploading to -proposed well before release
 - SRUs dance around timing issues with FinalFreeze
 - Could have better guides for when to break FinalFreeze and when to SRU
   - FinalFreeze expected to be stricter than SRU

If good enough for SRU, reasonable to consider for Freeze Exception, but there are timings.
Final Freeze is more strict than SRU - doesn't have 7 day testing.

Concern is transition widow between Oneiric Updates and Precise. Keeping it in synch - merges.

Need a lock down process. So people don't do pocket copies.

"If SRU accepted in -proposed before new archive is opened (0-day SRUs), task is opened in new release and assigned to -proposed uploader. Once archive is opened, don't accept -proposed uploads until corresponding dev release upload"

Who is responsible for accepting 0-day SRUs? SRU team, not release-team

2012/01/13 - needs to be populated with update procedures and expectations for stable release team members.
Link exists in ReleaseManagement


Work Items

Dependency tree

* Blueprints in grey have been implemented.