Applications 17.12 as LTS release?

[Albert Astals Cid]

El dilluns, 31 de juliol de 2017, a les 12:19:48 CEST, Elvis Angelaccio va 
escriure:
> Hi all,
> I'd like to discuss whether we can make the next Applications release an
> LTS release. What would be needed from a practical point of view? (changes
> to release/i18n scripts, etc.?)
> 
> About the schedule, I think we could release the LTS tarballs the same day
> we release the usual bugfix tarballs:
> 
> * release of 17.12.1
> * release of 17.12.2
> * release of 17.12.3
> * release of 18.04.1 + release of 17.12.4
> * release of 18.04.2 + release of 17.12.5
> * release of 18.04.3 + release of 17.12.6
> * release of 18.08.1 + release of 17.12.7
> * release of 18.08.2 + release of 17.12.8
> * release of 18.08.3 + release of 17.12.9
> 
> .. and so on.
> 
> Motivations for making 17.12 an LTS release:
> 
> * 17.12 due in December, next Plasma LTS due in January.
> * New openSUSE and Ubuntu LTS releases due next year.
> * 17.12 won't have kdelibs4 applications, so it would be a 'stable' target.
> 
> Of course we should ask distributions if they actually need an LTS for
> Applications (I can send another mail at distributions at kde.org after we
> agree that an LTS is doable), but I don't see why they wouldn't.
> 
> Comments?

What you need is buy-in from developers not from releasers, if developers 
agree this is a good idea, we sure can try to make this happen.

But since you came to the release-team i'll give you my part-of-release-team-
opinion anyway :D

I don't think it will work, and what we will have is something we call LTS but 
we don't really get much fixes in anyway.

If you look at the bugfixes in .MICRO releases, they are usually decreasing

17.04.1 - ~20 
17.04.2 - ~15
17.04.3 - ~25 <-- exception

16.12.1 - ~40
16.12.2 - ~20
16.12.3 - ~20

16.08.1 - ~45
16.08.2 - ~30
16.08.3 - ~20

16.04.1 - ~25
16.04.2 - ~25
16.04.3 - ~20

15.12.1 - ~30
15.12.2 - ~30
15.12.3 - ~15

There may be several reasons for that:
 * We actually fix all the bugs so there's fewer to fix for .3 (unlikely :D)

 * Developers forget there's a stable branch or if there's going to be another 
release of it so juts code the fix in master anyway (we know that people are 
kind of bad remembering the schedule)

 * After N months, code in stable diverges from master enough that developers 
only fix bugs in master since the pain of having to code the fix twice is too 
high.


And that is my developer-opinion, fixing bugs in a stable branch is often 
painful but doable, but having a LTS that branched long time ago is no fun at 
all.

This is something that companies (i.e. Red Hat et al) ask a lot of money for, 
exactly because of that, because it's not fun and because it's hard to make 
sure the patch even if it may apply, fixes the same thing in the same way 
without any side effect.

In my opinion this is something we should not be doing and I don't think it's 
a good investment of our developer-time, but who am I to say what our 
developers should be working? So again, goto first line, and try to convince 
the developers, not the releasers :)

Good luck,
  Albert


> 
> Cheers,
> Elvis