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 [email protected] https://lists.ubuntu.com/mailman/listinfo/technical-board
