On 2015-09-15 11:48 AM, Stéphane Graber wrote: > On Tue, Sep 01, 2015 at 05:45:26PM +0200, Martin Pitt wrote: >> Hello all, >> >> 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]. >> >> Thanks, >> >> Martin >> >> [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) > >> --- 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. > > I think we should also make it clear that any such new feature should be > present in the current development release and preferably in any > intermediary release the user may be able to upgrade to so not to cause > any potential regression or loss of support on upgrade. >
+1 from me with this change. Marc. -- technical-board mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/technical-board
