SRU policy: Allow new features in LTSes under certain conditions

[Marc Deslauriers]

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.