Release Team Members meeting

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

Discussion:

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 (https://wiki.ubuntu.com/PrecisePangolin/ReleaseTaskSignup)
- 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 - https://wiki.ubuntu.com/StableRelease/UpdateProcedures needs to be populated with update procedures and expectations for stable release team members.
Link exists in ReleaseManagement