Generalizing SRU policy for special cases/MREs

Marc Deslauriers marc.deslauriers at
Tue Sep 15 15:40:52 UTC 2015

On 2015-09-01 10:42 AM, Martin Pitt wrote:
> Hello all,
> over the years our SRU policy [1] has accumulated a fair amount of
> special cases [2] and exceptions for new microreleases [3]. There is a
> lot of commonality between them, mostly related to automated testing.
> Since most of these were added, a lot of projects have moved to a CI
> based development model; this includes Ubuntu itself, which is now
> running package integration tests for both the development series [4]
> and SRUs [5].
> The attached patch against [1] is my proposal for updating the SRU
> policy accordingly. It mostly extends the "When" section for the cases
> that we've seen in practice, and reduces [2] to just documentation
> about three packages (kernel, landscape, tzdata), which don't include
> a changed policy, just a "how to update this".
> This should go together with dropping [3]. A lot of the existing
> entries in [3] now fall under the revised "New upstream microreleases"
> policy (e. g. postfix, PostgreSQL, MariaDB, firefox, mesa), and others
> have been obsolete for quite a while (Ubuntu One, bzr). The section at
> the bottom ("SRU verification for Micro Release Exceptions") was
> included into the main [1] documentation (in spirit, not verbatim). I
> believe that the page [3] has never been very well maintained, as
> things become obsolete, there is no clear distinction between
> provisional and full exceptions, etc. Thus I believe setting a general
> policy and instead asking for linking to the QA policy in SRU bugs is
> a better and more dynamic approach.
> Comments, language improvements, etc much appreciated!
> Thanks,
> Martin
> P.S. I still have a TODO item to propose an amendment for introducing
> new features into LTS, such as the recently proposed "Ubuntu FAN" [6].
> I will do this after this cleanup got discussed/improved/accepted.
> [1]
> [2]
> [3]
> [4]
> [5]
> [6]

I think this proposal makes sense, as long as the SRU team is comfortable with
it. A +1 from me.


More information about the technical-board mailing list