El dilluns, 31 de juliol de 2017, a les 23:00:37 CEST, Albert Astals Cid va escriure: > 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 distributi...@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,
If you ask me what is a good investment of our developer-time, i think it's much better if we get the Flatpack pacakges of stable branch out and in good shape anyone running any distribution as old as it may be can get our fixes in time without us having to do the extra work of having yet-another-branch. Cheers, Albert > 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
