Re: SRU policy: Allow new features in LTSes under certain conditions - v2
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 technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: SRU policy: Allow new features in LTSes under certain conditions - v2
On Wed, Sep 16, 2015 at 06:59:36AM +0200, Martin Pitt wrote: > 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. > --- 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. > I'm happy with the wording on this version. The only niggling doubt that I have concerns the possibility that by setting this policy, we are opening the floodgates to all kinds of new packages being /allowed/ for inclusion in the stable releases, as a result DoSing the SRU team and leaving them to apply some other de facto policy, possibly one that is ultimately political in nature, to filter down the packages that are allowed through. Is that a likely outcome? Is it an acceptable one? If this does happen, what other steps should we take to fix it? -- 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
SRU policy: Allow new features in LTSes under certain conditions - v2
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. signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
