Ubuntu

Quality in a rolling release world

Registered by Nicholas Skaggs

The development cycle has changed in many ways since precise. With the advent of a potential rolling release, it's time to talk about the how we can adapt to better contribute in the changing landscape.

Blueprint information

Status:
Not started
Approver:
Jono Bacon
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
None
Definition:
New
Series goal:
Accepted for raring
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

Discussion:
   Cadence Weekshttp://pad.ubuntu.com/uds-1303-community-1303-quality-rolling

    Rolling Release
        Challenges?
        Rolling Release Stability
            Historically;
                developers should be able to run the dev release

                able to recover if somethng does happen

        How do we keep the LTS stable?
            continue on as-is
            more SRU's, more updates
            [cm-t]using stable version and LTS equivalent (ex: firefox ESR instead of firefox? [cjwatson] bit late for that)
        How do we do SRU's?
            Will it change to include new releases, as opposed to just bugfixes?
            Backports?
            [vibhav] New releases for packages which only have been deprecated?
        How does this all affect the other flavors?
            Depends if they chose LTS or rolling release
           That would require re-defining what an SRU is; we have traditionally been a tad more liberal with SRUs to LTSes given their nature, so if we are only going to have LTSes we should define this more clearly
           What will the foundation be for the flavors and what will the flavors have to worry about support-wise?
    Milestones
        Do we like monthly images/milestones/releases?
        How much testing makes sense for a monthly snapshot image?
            month to month upgrade testing?
            month to current upgrade?

Going from image testing to upgrade testing mentality
    how much post-install testing from automated upgrades go on?
    Images
        Daily Images
            LTS and rolling
        Monthly Images
            rolling
    Autopilot testing after upgrade?
    unify the iso post-isntall and post-upgrade tests, i. e. run the same set on both (plus a few extra ones after upgrade, such as "right kernel?")

    Recommended/supported upgrade paths:
    LTS -> LTS
    LTS -> Monthly snapshot ?
    Monthly snapshot -> Monthly snapshot (today)
    Daily -> monthly snapshot?
    LTS -> rolling needs to work anyway as we accumulate upgrade fixes for next LTS -> LTS, so we might just as well test and fix that everyday; that would imply the monthlies

(?)

Work Items

Work items for ubuntu-13.04-month-6:
[nskaggs] Plan and communicate next cycles changes for quality; according to release schedule, and teach board decisions: DONE

Work items:
[nskaggs] follow up with jibel to see how to improve upgrade testing: POSTPONED
[pwlars] Ensure that we have the right set of automated upgrade tests in place: POSTPONED

Nearby