Long term support release for Plasma?

[Philip Muskovac]

Hi,

Am 27.06.2016 um 14:28 schrieb Martin Graesslin:
> Hi distributions,
>
> in Plasma we are considering to add a long term support release. For this idea
> we want to get some feedback from your side to know how we should set this up.
>
> Here is an example (I mean it!) for how this could look like:
> * 5.8 first LTS release based on Qt 5.6 (which is also an LTS) for X11
> * every fourth release will be another LTS release, so with the 3 month cycle
> there is one LTS per year - 5.8, 5.12, 5.16
> * Support is for five release cycles, so with 5.13 the 5.8 LTS goes EOL, with
> 5.17 the 5.12 release goes EOL
> * bug fix release continue in the Fibonacci schedule till the EOL release
>
> We would like to know from you:
> * is that something which is useful to you?
So after initially being a bit surprised, I would probably appreciate 
this. Now let me put my Kubuntu hat on.

Kubuntu is on a 6 month release schedule with an LTS every 2 years in 
April. Our current LTS release ships Plasma 5.5 (because 5.6 was far 
late in our cycle to get done), and we're still backporting fixes in 
various places for it. Being able to ship an LTS with a Plasma release 
that receives upstream support until the .1 LTS update 3 months after 
release would be awesome for us and our users.
> * how often should we do an LTS release?
as I said, we're on a 2 year schedule, so that's all we really need. As 
other distributions are shifted, one per year sounds reasonable IMO.
> * how often should we do bug fix releases for an LTS?
I think the fibonacci updates haven been doing their job just fine? That 
would give ~8 updates over a year. As 13 and 21 weeks are a bit far 
apart between the last 2 releases, maybe switch to a 2 month schedule 
after .6? That would give 11 updates in total I think?. (I don't think 
more updates make sense, and you also need to find developers that are 
willing to fix something in the pre-pre-pre-current release)
> * how long should a LTS be supported?
I would be happy with your proposal, but it would be nice if security 
issues could be evaluated for the previous LTS as well. Doesn't need a 
release, a note in the advisory would be sufficient.
>
> Related to that:
> * what to do with frameworks?
> * Would you freeze the frameworks version or continue to backport newer
> framework versions to your distribution?
> * Would you want an LTS branch for frameworks as well?
> * What would you expect that to look like?
For frameworks I'm clueless, really. To be able to use a frameworks 
release in Kubuntu as an "update" it would have to...
- not cause any regressions [Not in plasma, not in any other software 
that uses it] (Hi behavior change when closing applications)
- not have any new or updated dependencies ("new" as in: we would need 
to add/update a 3rd party package)
- not have any component or pieces of a component removed (counts as 
"regression" [not frameworks, but hi kdepim for once removing unused 
public libs in a "bugfix" update])
- not have any components added (ok, that could probably be handled if 
really necessary)

That's why we and other distributions were asking for bugfix releases 
for frameworks 2 years ago. Did something change in the meantime that I 
missed?
>
> Looking forward to your input on this rather important topic.
>
> Cheers
> Martin

Here you have it and thanks for the idea ;)

Philip