Hi Martin, On Tue, Sep 01, 2015 at 05:45:26PM +0200, Martin Pitt wrote: > 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]. > [1] https://lists.ubuntu.com/archives/technical-board/2015-July/002122.html > [2] > https://lists.ubuntu.com/archives/technical-board/2015-September/002153.html > -- > Martin Pitt | http://www.piware.de > Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) I would add to this: > --- StableReleaseUpdates.specialcases 2015-09-01 16:33:58.559594596 +0200 > +++ StableReleaseUpdates.newfeatures 2015-09-01 17:41:37.611778569 +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. Once a new package has been introduced in a stable release, subsequent uploads of the package 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. > -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ [email protected] [email protected]
signature.asc
Description: Digital signature
-- technical-board mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/technical-board
