Stable Release Update process review.

1.) Refine, establish escalation workflow.
  a.) Required data. Establish required, requested
  b.) Tracking
2.) SRU status
 a.) bi-weekly agenda
3.) Validation
 a.) Ownership
 b.) Process

    Existing Process Documentation: https://wiki.ubuntu.com/StableReleaseUpdates

    Existing Kernel SRU Process: https://wiki.ubuntu.com/KernelTeam/KernelUpdates

    New Kernel SRU Process being piloted: https://wiki.ubuntu.com/Kernel/StableReleaseCadence

    Overall SRU Status: http://people.ubuntu.com/~ubuntu-archive/pending-sru.html

- a lot of SRUs stay in -proposed SRUs because nobody tests them
Goal: Want to see end to end ownership and not have SRU's with fixes expiring out of proposed.
pitti: policy today self filters, easy to propose SRU's, and some don't make it. Large throughput.
MartinS: 10-15 SRUs going in trying to prioiritize.
For community person, how find something to work on? Pick up from:
http://people.canonical.com/~ubuntu-archive/pending-sru.html
What about all or nothing aspect of package upgrade across releases?
Use of pending tree? Where is it documented?
Missing out on testing community opportunity?
Writing formal testcase - odds of getting the bug solved go up. -> should be more strict about it again
Different level of testing is required for some packages (not all packages are equal in terms of dependencies).
- applications
- libraries
- infrastructure - xorg, boot, toolchain.
sometimes bugs are harder to reproduce (random crashes), writing test cases is hard -> focus on regression testing, like "test this 20 times, if you can't reproduce you are not a valid tester"
Debian installer -> netboot.
meeting:
 - what agenda items do we want to cover each week?
   * major SRUs which break a lot of people's systems, broken down by release
- review of top SRUs from all teams
- announcement of potential SRUs which might or might not be useful
   - capacity balancing between development and release cycle for support.
- highlight what is about to fall off and get MartinS's team involved
Tie in to patchpilot program?
EtienneG's case:
- upstream created one branch that fixes 9 bugs.
    vorlon: sympathy for both positions
    upstream lost interest in participating, fustration... screeching halt.
    9 URLs/git commits would have been one possible way.
- attracting sponsors to get it into proposed.
Should we clarify how to work with patch pilots to clarify this?
Should we update the documentation? yes
Documentation is not reflecting how upstream microreleases should be handled.
In process things seem to work... bug fix micro release vs. upstream chaning features.

Work items:
[pitti] contact LP team to change -proposed release files to set NotAutomatic: yes (like -backports) -> bug 800515 (linked as WI): DONE
[mvo] change update-manager to offer -proposed SRUs: POSTPONED
[pitti] change call for testing email to point to updated documentation: BLOCKED
[pitti] update documentation with new instructions on installing single package, pinning up all of -proposed to get everything: BLOCKED
[kate.stewart] interlock with release management from Linaro for assessing SRUs/adding results?: BLOCKED
[martins] update wiki page to include "this is a good test case", "this is a bad test case"
[kate.stewart] start to put a proposed set of package impact (dependency based) with the goal of improving the testing for higher impact areas - ie. running automated system testing for areas that contain those components. Have more people test for those before going to updates, etc...): POSTPONED
[pitti] clarify SRU documentation for patches for multiple bugs (one debdiff OR individual patches): DONE
[dholbach] ensure that the patch pilot documentation highlights this case (SRU policy linked to 3 times, additionally added request to bug 702005): DONE
[kate.stewart] (or martins) rework weekly agenda : POSTPONED
[pitti] clarify documentation about microrelases which only fix a few bugs: DONE