SRU micro version update exception
Allow for an exception in SRUs to the "patch must be as small and unintrusive as possible" requirement for specific packages that meet the criteria:
- upstream supports micro-version updates to stable releases
- upstream has a sufficiently high level of regression testing for their stable releases
- regression tests are always run on the update before it is released (e.g. by being enabled in the package's build)
The technical board will have the responsibility to maintain and review the list of packages that are exceptions to the SRU rule, as well as approve package additions.
Changes to the exception list must be brought to the TB via email (firstname.lastname@example.org). The request is expected to include justification against the above criteria.
- Changes can be approved via any single TB member. (Please link to the discussion when adding to the MRE list.)
- The SRU team can revoke exceptions when there is evidence that an MRE is producing unacceptable regressions.
- Having a history of successful SRUs is strong evidence for granting an MRE. However, it may not be possible to perform an SRU in the face of a large number of upstream bug fixes (which is the cause for an MRE being pursued). In this case, if the TB feels (with evidence from package maintainers and the SRU team) that a "provisional MRE" (one-time MRE) is safe to be put in place, an SRU can proceed as if a standing MRE was in place. On the next SRU, the provisional MRE would need to be either removed, renewed, or made into a full standing MRE.
- Approved standing exceptions:
- mozilla-thunderbird, thunderbird
- clamav (approved on 2009-01-09)
- chromium-browser, chromium-codecs-ffmpeg, gyp (approved on 2010-11-02)
KDE (approved on 2010-11-16, extended on 2013-07-22, extended on 2013-09-30)
Banshee (approved on 2011-06-30)
- postfix (approved on 2012-05-14)
- Ubuntu One (approved on 2012-06-19)
GNOME (only the core modules and apps, not the entirety of what is hosted on gnome.org; roughly corresponds to the gnome-apps, gnome-suites-core, and gnome-suites-core-deps modules on http://git.gnome.org/browse/jhbuild/tree/modulesets) (approved on 2012-06-22)
sssd (approved on 2013-01-08)
xorg-server (and only that source package) (2013-04-01)
MySQL (approved on 2014-02-07)
MariaDB (approved on 2014-05-12)
Xen (approved on 2013-07-22)
Nova, Glance, Horizon, Keystone (to unblock SRU on 2012-06-25; provisional → full on 2014-05-12)
Cinder, Quantum (Neutron) on 2012-12-03; provisional → full on 2014-05-12
extended to include neutron flavors (neutron-fwaas, neutron-lbaas, neutron-vpnaas) on 2015-05-03
Ceilometer, Heat on 2013-10-08; provisional → full on 2014-05-12
Oslo (python-oslo.concurrency, python-oslo.config (oslo.config < wily), python-oslo.context, python-oslo.db, python-oslo.i18n, python-oslo.log, python-oslo.messaging (oslo.messaging < wily), python-oslo.middleware, python-oslo.policy, python-oslo.rootwrap (oslo-rootwrap < wily), python-oslo.serialization, python-oslo.utils, python-oslo.versionedobjects, python-oslo.vmware) on 2015-07-21
ceph for Ubuntu >= 12.10 and ceph upstream LTS releases 2013-02-25; provisional → full on 2014-05-12
openvswitch for Ubuntu >= 12.04 LTS 2013-08-19; provisional → full on 2014-05-12
vlc (2012-07-23); provisional → full on 2014-05-27
- Provisional exceptions:
Mesa (2012-07-23 - SPECIAL CASE: piglit test suite is not in-tree, needs to be run on real hardware)
New versions (not just microreleases) of juju-core 2014-08-05: juju-quickstart needs to be tested as part of the verification; manual testing against existing deployments from older releases until automation is in place
- For MRE packages only, it can generally be assumed that bugs claimed to be fixed have actually been fixed upstream, and it is not necessary to manually independently verify them. (Some bugs may deserve specific verification if for example they are hard to reproduce upstream.)
- Testing should generally concentrate on broad smoke tests to make sure no new regressions have been introduced.
- The upstream test suite should be run from the built packages.
- The diff should be reviewed to ensure no accidental or inappropriate changes were introduced during the micro-release.
When the preceding steps have been done, the headline bug (only) should be marked verification-done