What does LTS *actually* mean

[Harald Sitter]

On Thu, Jan 16, 2014 at 6:39 AM, Rohan Garg <rohangarg at kubuntu.org> wrote:
> On Wednesday 15 January 2014 14:04:57 Harald Sitter wrote:
>> I was just wondering. What does LTS mean? In terms of supporteeness?...
>>
>
> While I can't objectively answer the questions posed in the original email,
> here are my 2 cents on the topic of supporteeness :
>
> * To me it seems like LTS's are marketed as releases which will continue
> getting support for the KDE Workspaces and Applications. This is absolutely
> not true since KDE upstream makes no promises of supporting these products for
> the lifetime of our LTS support ( This has changed with the recent
> announcement of freezing KDE Workspace, but since most of the effort will be
> focused on KF5, I doubt there will be alot of motivation to fix bugs in kde-
> workspace 4.11)

As I mentioned yesterday on IRC. I think support is an overused word
which really means too many things and most of the time it means them
all at once. It may well be that because of this overuse we are not
exactly clear what an LTS is supposed to achieve. I am however
reasonable certain it does not mean we push continuous bug
fixes/improvements to all packages. In fact that's not even really
what it means to KDE. As their commitment is not really continuous (as
in: all bugfixes must be isolated and backported to bugfix release).

Since KDE has no central authority or team to actually ensure bugfix
backporting this is still up to every developer. If they consider a
bugfix backport too much work they may simply not do it.  And in fact
I seem to recall SC releases with <10 bugfixes, not because all bugs
had been fixed, but because all important ones were fixed or the
developers moved attention to master.
The support commitment in my eyes is really between three parties
a) the release team telling the developers that they can push fixes to
branch, the release team then will take care of rolling that branch
into a bugfix release
b) the developers telling the release team to roll a release from
branch x because the developers are putting fixes there
c) the release team and developers telling the user that they will
aggregate and release bugfixes to version x

I am not saying that this is different from our process, but it
certainly shows why support means different things. For the release
team 'support' is creating new releases from branch x. For the
developers 'support' is throwing all bugfixes at branch x in addition
to master. For the user 'support' is getting releases with bugfixes
from branch x (in case the twist wasn't obvious, the user expects two
things but the creating parties are each only responsible for one :P).

So, perhaps to find out what an LTS release is and does, we should
first try to find out what support means ;)

> * Since upstream does not offer any long term support, it's up to the packagers
> to backport non feature fixes from KDE Upstream to the LTS release, except that
> with the current workload this is not feasible and there is no guarantee that
> these non feature commits will even work with older versions of KDE.

The not worky part is why we have a 7 days proposed testing period.
But yeah, I don't think LTS must get every fix. And actually for a
number of reasons.

- To get a fix into LTS the fix needs to be pushed through up to 5
releases (I think ... devel, stable, stable-old, LTS, LTS-old), even
in the more fortunate scenario that stable-old has gone EOL, you still
end up with 4 releases if you want to push a fix in the previous LTS
(what with LTSs now being 6 years supported).
- Getting a fix into a release require substantial work to prepare the
SRU (patch creation, package creation, test building, possibly a local
test before upload), writing fix verification instructions and so
forth).
- Random bugfixes run danger of not being verified. This is actually a
big thing. I definitely had some 4 SRUs (~12 individual verifications)
left undone for lack of verification. Considering all the effort put
into SRUs this becomes a gigantic waste of time...

> * Personally, I feel that a LTS release means that Kubuntu Developers should
> try and provide KDE SC feature releases for the LTS release via the Kubuntu
> Backports PPA. This is the only way we can keep in sync with upstream's
> promise of support of Applications and Workspaces.

... see above about the meanginglessness of support :P ...
I do agree with the general notion of backporting new releases for as
long as possible and supported though. I'll refrain from detailing
why, for now, because the mail is already rather long :P

> * I also think that we should try and test the backported packages against the
> LTS HW enablement stack [1] since upstream usually expects a reasonably up-to-
> date software stack for newer KDE SC releases.

Doesn't seem to be as usual, given that we still can backport to 12.04.

HS