Re: SRU policy: Allow new features in LTSes under certain conditions
Hey Robie, sorry for the late answer, I missed your reply. Robie Basak [2015-09-02 10:51 +0100]: > On Tue, Sep 01, 2015 at 05:45:26PM +0200, Martin Pitt wrote: > > 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. > > For clarity, let me call the above requirements "the quality criteria". > > Consider a new feature where the proposed LTS update does meet the > quality criteria. Who will decide whether this feature is acceptable to > SRU to the LTS? The intention is that the SRU team who reviews the change decides whether this matches the policy, as usual. If the SRU team has doubts about a particular change, they should continue to express that in the bug, and/or appeal to the TB. > Would each proposed feature still need to go individually to the TB for > approval? Or would this new policy give uploaders the ability to add new > features to the LTS directly, since the SRU team would simply approve it > under this new policy? That was the idea: We want to greatly reduce the number of special cases that we need to document and check explicitly, and instead generalize the principles upon we granted them into the main policy, so that this becomes less arbitrary. > For example, what should a sponsor do to handle a new feature in the > sponsorship queue? Just upload if it meets the quality criteria, to be > accepted by the SRU team after they have double-checked? Or should extra > steps be taken to determine if we want the new feature in the LTS? There is only so much common sense which you can formalize. This is certainly not meant to swamp LTSes with all kinds of corner case new features, they should continue to be the exception. But yes, the idea of the policy is that everyone can check whether the criteria match and we avoid long turnarounds with individual discussions for exceptions. As a sponsor you take responsibility for the uploaded change, be it in the devel series or SRU; so if as a sponsor you are convinced that SRUing that new feature is a good idea, safe, and matches the above policy, then go ahead. The SRU team will review the change anyway. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- 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
Re: Generalizing SRU policy for special cases/MREs
On 2015-09-01 10:42 AM, Martin Pitt wrote:
> Hello all,
>
> over the years our SRU policy [1] has accumulated a fair amount of
> special cases [2] and exceptions for new microreleases [3]. There is a
> lot of commonality between them, mostly related to automated testing.
> Since most of these were added, a lot of projects have moved to a CI
> based development model; this includes Ubuntu itself, which is now
> running package integration tests for both the development series [4]
> and SRUs [5].
>
> The attached patch against [1] is my proposal for updating the SRU
> policy accordingly. It mostly extends the "When" section for the cases
> that we've seen in practice, and reduces [2] to just documentation
> about three packages (kernel, landscape, tzdata), which don't include
> a changed policy, just a "how to update this".
>
> This should go together with dropping [3]. A lot of the existing
> entries in [3] now fall under the revised "New upstream microreleases"
> policy (e. g. postfix, PostgreSQL, MariaDB, firefox, mesa), and others
> have been obsolete for quite a while (Ubuntu One, bzr). The section at
> the bottom ("SRU verification for Micro Release Exceptions") was
> included into the main [1] documentation (in spirit, not verbatim). I
> believe that the page [3] has never been very well maintained, as
> things become obsolete, there is no clear distinction between
> provisional and full exceptions, etc. Thus I believe setting a general
> policy and instead asking for linking to the QA policy in SRU bugs is
> a better and more dynamic approach.
>
> Comments, language improvements, etc much appreciated!
>
> Thanks,
>
> Martin
>
> P.S. I still have a TODO item to propose an amendment for introducing
> new features into LTS, such as the recently proposed "Ubuntu FAN" [6].
> I will do this after this cleanup got discussed/improved/accepted.
>
> [1] https://wiki.ubuntu.com/StableReleaseUpdates
> [2] https://wiki.ubuntu.com/StableReleaseUpdates#Special_Cases
> [3] https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
> [4]
> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
> [5] http://people.canonical.com/~ubuntu-archive/pending-sru.html
> [6] https://lists.ubuntu.com/archives/technical-board/2015-July/002122.html
>
I think this proposal makes sense, as long as the SRU team is comfortable with
it. A +1 from me.
Marc.
--
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
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. > * 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. > > -- > technical-board mailing list > technical-board@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/technical-board -- Stéphane Graber Ubuntu developer http://www.ubuntu.com signature.asc Description: Digital signature -- 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
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 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
Re: Generalizing SRU policy for special cases/MREs
On 2015-09-02 05:28 AM, Scott Kitterman wrote:
> On Tuesday, September 01, 2015 04:42:26 PM Martin Pitt wrote:
>> Hello all,
>>
>> over the years our SRU policy [1] has accumulated a fair amount of
>> special cases [2] and exceptions for new microreleases [3]. There is a
>> lot of commonality between them, mostly related to automated testing.
>> Since most of these were added, a lot of projects have moved to a CI
>> based development model; this includes Ubuntu itself, which is now
>> running package integration tests for both the development series [4]
>> and SRUs [5].
>>
>> The attached patch against [1] is my proposal for updating the SRU
>> policy accordingly. It mostly extends the "When" section for the cases
>> that we've seen in practice, and reduces [2] to just documentation
>> about three packages (kernel, landscape, tzdata), which don't include
>> a changed policy, just a "how to update this".
>>
>> This should go together with dropping [3]. A lot of the existing
>> entries in [3] now fall under the revised "New upstream microreleases"
>> policy (e. g. postfix, PostgreSQL, MariaDB, firefox, mesa), and others
>> have been obsolete for quite a while (Ubuntu One, bzr). The section at
>> the bottom ("SRU verification for Micro Release Exceptions") was
>> included into the main [1] documentation (in spirit, not verbatim). I
>> believe that the page [3] has never been very well maintained, as
>> things become obsolete, there is no clear distinction between
>> provisional and full exceptions, etc. Thus I believe setting a general
>> policy and instead asking for linking to the QA policy in SRU bugs is
>> a better and more dynamic approach.
>>
>> Comments, language improvements, etc much appreciated!
>>
>> Thanks,
>>
>> Martin
>>
>> P.S. I still have a TODO item to propose an amendment for introducing
>> new features into LTS, such as the recently proposed "Ubuntu FAN" [6].
>> I will do this after this cleanup got discussed/improved/accepted.
>>
>> [1] https://wiki.ubuntu.com/StableReleaseUpdates
>> [2] https://wiki.ubuntu.com/StableReleaseUpdates#Special_Cases
>> [3] https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
>> [4]
>> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excus
>> es.html [5] http://people.canonical.com/~ubuntu-archive/pending-sru.html
>> [6] https://lists.ubuntu.com/archives/technical-board/2015-July/002122.html
>
> I think this is generally a good change. The one suggestion I have is to
> adjust the "New upstream microreleases" section slightly. Starting with the
> last line added in that hunk of the patch:
>
> ... it is also generally acceptable to upload new microreleases (~ubuntu-sru
> will make the final determination). The upstream QA process must be
> documented/demonstrated and linked from the SRU tracking bug. In other cases
> where such upstream automatic testing is not available, exceptions must still
> be approved by at least one member of the Ubuntu Technical Board.
>
> The reason I leave this in is that the proposed language doesn't cover all
> the
> current micro-release exceptions. Postfix is an example where we have tests,
> but they don't fit the listed criteria, but I am completely comfortable with
> the mix of upstream fix policy in point releases and our own tests being
> adequate QA to make the MRE that's in place appropriate.
>
I think this is a reasonable request.
Marc.
--
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
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.specialcases2015-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 technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
