SRU policy: Allow new features in LTSes under certain conditions - v2

Martin Pitt martin.pitt at
Tue Sep 22 14:22:32 UTC 2015

Hello all,

Steve Langasek [2015-09-17 14:28 -0700]:
> The only niggling doubt that I have concerns the possibility that by setting
> this policy, we are opening the floodgates to all kinds of new packages
> being /allowed/ for inclusion in the stable releases, as a result DoSing the
> SRU team and leaving them to apply some other de facto policy, possibly one
> that is ultimately political in nature, to filter down the packages that are
> allowed through.

This should remain a relative rare exception. I. o. if the SRU team
feels swamped with having to check several new backported features
every week, I'd definitively call this an abuse, and we'd need to
revisit this paragraph.

In some way this is similar to the SRUs that we've had so far: E. g.
I've seen many uploads to non-LTSes for fixes which are quite frankly
just a waste of everybody's (uploader, SRU team, verifying user's)
time. But so far I have the impression that the large majority of SRUs
is well justified, particularly to LTSes (where SRUs matter much

> Is that a likely outcome?  Is it an acceptable one?

No and no, I think.

> If this does happen, what other steps should we take to fix it?

We should take a look at the proposed features, which ones we deemed
appropriate and which not, and find a pattern there; and then codify
this into the policy.


Martin Pitt                        |
Ubuntu Developer (  | Debian Developer  (
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <>

More information about the technical-board mailing list