What does LTS *actually* mean

[Scott Kitterman]

On Friday, February 07, 2014 09:41:29 Harald Sitter wrote:
> On Thu, Feb 6, 2014 at 6:54 PM, Scott Kitterman <ubuntu at kitterman.com> 
wrote:
> > On Thursday, February 06, 2014 11:27:02 Harald Sitter wrote:
> >> Thanks for the thoughts.
> >> 
> >> As I am currently writing a policy on this matter, currently the
> >> characteristics of a Kubuntu LTS seem to be:
> >> 
> >> * Long-term KDE SC backport target (PPA)
> >> * Long-term security update target (-security)
> >> * Long-term stable update target (-proposed) [stable updates policy
> >> applies - ensuring time is not wasted]
> >> * Extra permissive stable release update handling while LTS=latest stable
> >> 
> >> Anyone got any final additions/objections?
> > 
> > What does the last one mean in practical terms?  The stable update
> > permissions we have are from the tech board, so we can't modify them
> > unilaterally.
> tldr: policy creates artificial requirements before being able to do a
> SRU that is not a patch release, those requirements are to be ignored
> for the first 6 months to facilitate plentiful annoyance fixes in an
> LTS release.
> 
> Another policy deals with when to do SRUs, it is intended to restrict
> SRUs to the most likely to succeed subset as to avoid time waste. I
> was thinking that up to 6 months after LTS release a more lax
> restriction (alas, permissive was a badly chosen word) should apply
> because in practise we usually push more SRUs into LTS after its
> release (compared to regular releases anyway).
> To reflect this LTS releases should be encouraged to receive plenty of
> SRUs the first 6 months, and for that the requirements for
> availability of testers and all that should be disregarded during that
> period.
> 
> https://wiki.ubuntu.com/Kubuntu/Policies#Misc_.28.28NEW.29.29

OK.  How about "additional emphasis on" instead of "extra permissive"?  We 
can't be more permissive than the SRU team rules allow without additional 
exceptions from the tech board.

Scott K