Tech Board discussion about new MOTU SRU policy

Martin Pitt martin.pitt at
Wed Nov 21 20:34:16 GMT 2007

Hello MOTU council,

yesterday the Technical Board Meeting discussed the SRU
policy for universe.

A while ago, the MOTU-SRU team [1] was declared being obsolete, and
the SRU process for universe [2] changed so that every MOTU could
decide what is appropriate for an SRU.

This has now led to a situation where we have a lot of universe SRUs
which I deem inappropriate, and there is no peer review at all.
Without anyone else filtering bad updates, the main SRU team (read:
me) now gets to sort out every update, of which there are quite a few.

Thus the following was blessed by TB yesterday:

--------- 8< -----------
We have too much action on universe SRUs with highly intrusive
patches, which both destabilize stable releases and divert too much
resources (both from MOTU developers and main SRU team) away from
fixing the development release, which should be the primary focus of
attention. We should aim to do good QA on the development release
instead of always playing catch-up on stables.

Proposed changes to rectify this:
(1) Reintroduce a policy what kinds of bugs should be fixed in stable
    releases. Ideally this should be identical to the one for main

(2a) Reinstate the MOTU-SRU team and require an ack from a team member
    before the upload is done.


(2b) Require acks of at least two other MOTUs before a universe SRU bug
     is considered approved and ready to upload.

(3) The archive admins will reject any upload which does not fulfill
    above criteria. They will reject uploads without any notice if the
    changelog does not have a bug reference. (It takes much time to
    find the corresponding bug report otherwise, or just to find that
    there is none at all.)
---------- 8< -----------

The MOTUs themselves should decide between (2a) and (2b). Right now,
opinions are a bit ambiguous between the two ([4], [5], [6], [7]).  My
advice would be (2a) (dedicated team) to build up some experience and
consistent policy in the team, but if this proves to be a bottleneck,
(2b) should still work; at least this would show that there is a more
general perception of which things are considered important than just
the package maintainer.

Can this be discussed at the next appropriate meeting? Then [2] should
be updated to the new policy.

Thank you!



Martin Pitt
Ubuntu Developer
Debian Developer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : 

More information about the ubuntu-devel mailing list