On Wed, Sep 16, 2015 at 06:59:36AM +0200, Martin Pitt wrote: > Hello again, > > Martin Pitt [2015-09-01 17:45 +0200]: > > occasionaly we get a request to introduce a new package into LTSes. > > This is usually unproblematic as there is a miniscule chance to break > > existing installations (unless the Package uses > > Conflicts:/Replaces:/Provides:), which should obviously not be > > allowed). In July however we got a more intrusive request for > > introducing Ubuntu FAN into trusty [1]. This was granted a special > > exception by the TB, but it would be good to generalize the principles > > upon we agreed to this. > > > > I therefore propose the following amendment to the policy, relative to > > the changes proposed in [2]. > > This updated proposal incorporates the suggested changes from Stéphane > and Steve. > > Martin > > -- > Martin Pitt | http://www.piware.de > Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
> --- StableReleaseUpdates.specialcases 2015-09-16 06:44:07.135737058 +0200 > +++ StableReleaseUpdates.newfeatures 2015-09-16 06:51:45.290663836 +0200 > @@ -49,6 +49,7 @@ > > * Bugs which do not fit under above categories, but (1) have an obviously > safe patch and (2) affect an application rather than critical infrastructure > packages (like X.org or the kernel). > * For Long Term Support releases we regularly want to enable new hardware. > Such changes are appropriate provided that we can ensure not to affect > upgrades on existing hardware. For example, modaliases of newly introduced > drivers must not overlap with previously shipped drivers. This also includes > updating hardware description data such as udev's keymaps, media-player-info, > mobile broadband vendors, or PCI vendor/product list updates. > + * For Long Term Support releases we sometimes want to introduce new > features. They must not change the behaviour on existing installations (e. g. > entirely new packages are usually fine). If existing software needs to be > modified to make use of the new feature, it must be demonstrated that these > changes are unintrusive, have a minimal regression potential, and have been > tested properly. To avoid regressions on upgrade, any such feature must then > also be added to any newer supported Ubuntu release. Once a new > feature/package has been introduced, subsequent changes to it are subject to > the usual requirements of SRUs to avoid regressions. > * New versions of commercial software in the Canonical partner archive. > * '''FTBFS'''(Fails To Build From Source) can also be considered. Please > note that in '''main''' the release process ensures that there are no > binaries which are not built from a current source. Usually those bugs should > only be SRUed in conjunction with another bug fix. > +1 from me. -Kees -- Kees Cook -- technical-board mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/technical-board
