Re: EOL business
On Wednesday, 9 July 2025 22.30.21 Central European Summer Time Nate Graham wrote: > Tricky situation. > > It feels a bit stinky if we strictly define "supported" to mean "will > receive further bug-fix releases", since then the final bug-fix release > is always unsupported the moment it's released. > > But on the other hand, how are we going to support it if no more bug-fix > releases are planned? it kinda has to be, no? It could be said that the last supported is the last release - 1, because that's what it kinda is, no? -- Marco Martin
Re: EOL business
I've drafted up two MRs lts removal: https://invent.kde.org/sysadmin/bugzilla-bot/-/merge_requests/33 support removal: https://invent.kde.org/sysadmin/bugzilla-bot/-/merge_requests/34 The latter tries to avoid the word support, being so ambiguous, while conveying that things just won't get releases anymore. The basic timeline would then be as suggested: With the release of 6.4.5 the 6.4 series turns almost_eol and with the release of 6.4.6 it turns eol. HS
Re: EOL business
A is fine. We can tweak the text to fit our situation rather than making the process fit the current text. We should say what we want to convey without referencing the word "supported" anywhere which is a phrase we should avoid when it's ambiguous. Something like: "A new version of Plasma <%= plasma %> is available, which may have already addressed your current issue. Only critical and security fixes will be backported to this release. Blah blah blah, please upgrade"
Re: EOL business
I'd say it's fine, there needs to be a last one. Also, we make the rules and we can break them. If a new release needs making we have all the means and agency to do so. Aleix On Wed, Jul 9, 2025 at 10:30 PM Nate Graham wrote: > > Tricky situation. > > It feels a bit stinky if we strictly define "supported" to mean "will > receive further bug-fix releases", since then the final bug-fix release > is always unsupported the moment it's released. > > But on the other hand, how are we going to support it if no more bug-fix > releases are planned? > > Perhaps we need a more flexible definition of "supported". > > > Nate
Re: EOL business
Am 10.07.25 um 09:52 schrieb Harald Sitter: On Wed, Jul 9, 2025 at 10:30 PM Nate Graham wrote: since then the final bug-fix release is always unsupported the moment it's released. [...]> We could decide that EOL happens six months after the last release, but does that really change anything for the user? (Preamble: I'm using 6.3 as example, but of course this applies to any other version, too). TLDR: I think the maximum reasonably possible extension has already been agreed upon during the Graz Plasma sprint, i.e. the addition of another bugfix release (6.3.6) . Longer reasoning: Giving distros / admins more time to switch over to a new version could potentially reduce the number of users affected by the EOL by quite a lot (depending on the extension). But there'll always be people remaining on 6.3 for much longer, so some EOL date must be set, anyway. Extending releases for another 6 months (or 3 months, or whatever) obviously comes with a great workload: Bug triaging, developing and/or backporting fixes, testing, CI, support-confusion (e.g. if users fail to report affected version), ... It would kind-of-sort-of make every release an LTS release, and Nate already wrote about why this is causing issues AND might not even be super useful. [1] Some distributions also have much longer update-cycles (debian) and won't benefit from a "short" extension. Then again, AFAIK debian didn't even ship *any* LTS bugfix releases for 5.27 (I think they stayed at 5.27.5 for bookworm, didn't they? ) There's only a limited number of people, resources and work hours (often in spare time) that can be spent on the entire project, and I don't think spreading those resources thinner than they already are will actually benefit the project and the community as a whole. Coming back to my TLDR: In my opinion (as someone doing none of the heavy lifting), having the 6th bugfix release is already trying to consider the user's (justified) needs to the maximum extent that can reasonably be offered. Also: let's not forget that there have been 6 bugfix releases already at this point, most serious bugs should probably have been fixed by now. If something critical comes up (e.g. a bad regression causing crashes left and right), exceptions could probably be made - but from past experience, that will most likely be super rare and thus should not be taken into account in the default actions and messaging. [...] I think it better for everyone involved if we are honest with the user here. "6.3.6 is as good a 6.3 as you will get, if you still have problems you need to upgrade to 6.4 and we may be able to find a solution." I agree, and I think it also comes down to the message. Here's a draft (I'm a non-native speaker): "This is an automatic reply, but we gave it a lot of thought: Thank you for taking time to report this issue. Reporting issues is helping the KDE community to improve our software. Unfortunately, no further releases for Plasma Y (your reported version) are scheduled. The KDE community (including a lot of volunteers) does not have the resources to verify or fix issues for versions of Plasma that will no longer receive further release. We are very sorry that we can't help you with your issue. If possible, please update to the currently supported Plasma X and check, if the issue is present there, too. If it is not possible to update, here's some things you could do: - report the issue to your distribution. Maybe someone can have a look (but be advised that they are usually under heavy work load, too) - find someone willing to fix the issue (most likely by paying them for the work) or try to fix the issue yourself - ask in our forums for a possible solution (workaround) of the issue This report will be automatically closed now. Feel free to re-open it if the issue is still present in Plasma X." Of course, a lot of people will not read this (or any) message, they'll just see "wont-fix, closed" and go raging about it on SocialMedia, but there's probably nothing that can be done about that... Best regards Martin HS [1] https://pointieststick.com/2025/05/01/notes-from-the-graz-plasma-sprint/ starting at heading "Plasma LTS"
Re: EOL business
On Wed, Jul 9, 2025 at 10:30 PM Nate Graham wrote: > since then the final bug-fix release > is always unsupported the moment it's released. Is that a problem though? Like I get the optics aren't ideal but that is what is actually happening here. The moment the last patch release hits the version is "done". It has reached its end of life and won't receive further updates. You can keep using it but it will not receive further updates from us. Distributions may choose to provide support on their own but for that to happen bugs need to be reported to them, not us. We could decide that EOL happens six months after the last release, but does that really change anything for the user? They can report bugs, sure. In the super ideal scenario that bug even gets fixed in master. Then what? It's the LTS conundrum all over again, except now we don't even have a release-when-necessary plan. Cynical looking at it, the much more likely scenario is that either someone wastes time triaging an already fixed bug or it remains unclear if the bug even affects master and it gets ignored. I think it better for everyone involved if we are honest with the user here. "6.3.6 is as good a 6.3 as you will get, if you still have problems you need to upgrade to 6.4 and we may be able to find a solution." HS
Re: EOL business
On Wed, Jul 9, 2025 at 11:21 AM Ben Cooksley wrote: > > On Wed, Jul 9, 2025 at 8:13 PM Harald Sitter wrote: >> >> Servas! > > > Hello! > >> >> >> So, at the plasma sprint we decided to have an extra release for -1 >> (e.g. 6.3), after a new major release (e.g. 6.4), such that we can >> actually say -1 is "supported" while distros migrate to current >> release (6.4) >> >> Since that is a bit abstract the idea here was that we have >> >> - 6.3.5 >> - 6.4.0 >> - (6.3 is now almost out of support) >> - 6.3.6 >> - (6.3 is now out of support because we have no more releases to fix bugs in) >> >> Now to my mind that also meant our bug bot would put that into >> practice exactly as described, but on matrix there was some discontent >> with this. Let's figure this out. > > > Does this mean that we need to keep CI support around for three branches > (development, new stable and old stable) now? > This is the first time i'm hearing of this if that is the case... It's the same thing as https://www.mail-archive.com/[email protected]/msg122714.html David
Re: EOL business
Tricky situation. It feels a bit stinky if we strictly define "supported" to mean "will receive further bug-fix releases", since then the final bug-fix release is always unsupported the moment it's released. But on the other hand, how are we going to support it if no more bug-fix releases are planned? Perhaps we need a more flexible definition of "supported". Nate
Re: EOL business
On Wed, Jul 9, 2025 at 8:13 PM Harald Sitter wrote: > Servas! > Hello! > > So, at the plasma sprint we decided to have an extra release for -1 > (e.g. 6.3), after a new major release (e.g. 6.4), such that we can > actually say -1 is "supported" while distros migrate to current > release (6.4) > > Since that is a bit abstract the idea here was that we have > > - 6.3.5 > - 6.4.0 > - (6.3 is now almost out of support) > - 6.3.6 > - (6.3 is now out of support because we have no more releases to fix bugs > in) > > Now to my mind that also meant our bug bot would put that into > practice exactly as described, but on matrix there was some discontent > with this. Let's figure this out. > Does this mean that we need to keep CI support around for three branches (development, new stable and old stable) now? This is the first time i'm hearing of this if that is the case... > > The messaging involved is thusly: > > almost_eol gets a comment with this text > > https://invent.kde.org/sysadmin/bugzilla-bot/-/blob/master/data/almost-eol.txt.erb?ref_type=heads > > eol gets a comment **and closed** with this text > > https://invent.kde.org/sysadmin/bugzilla-bot/-/blob/master/data/eol.txt.erb?ref_type=heads > > Now as for timing these we have two options: > > a) things happen as described. 6.3.6 marks the end of 6.3 support -- > if users want support for 6.3 they have to go to their distro (i.e. > 6.3 became almost_eol with the release of 6.4.0 and is as of yesterday > eol) > > b) 6.3 becomes eol at an arbitrary point in the future (when?) but we > won't be able to fix bugs. we have to guess or test whether a bug is > applicable for 6.4/master > > Suffice to say I am for a) because b) seems to entirely defeat the > purpose of what we set out to do. We'd still get outdated bug reports > and we'd again have people on a release nobody really supports and > everyone shrugging as to who exactly will fix their bugs or care about > their reports. > > We could delay a) by a week or so, but that puts extra things to > remember on the release manager's plate, I would avoid that if > possible. > > Thoughts? > > HS > Thanks, Ben
Re: EOL business
Am 09.07.25 um 10:13 schrieb Harald Sitter: eol gets a comment **and closed** with this text https://invent.kde.org/sysadmin/bugzilla-bot/-/blob/master/data/eol.txt.erb?ref_type=heads Semi-OT: I think the LTS part of that message should be removed, as there are no more (planned) LTS releases? Best regards Martin
