<!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <div class="moz-cite-prefix">On 11/23/23 23:02, Steve Langasek wrote: </div> <blockquote type="cite" cite="mid:ZWAuVb3LTakLGWwm@homer.dodds.net"> <pre class="moz-quote-pre" wrap="">On Thu, Nov 23, 2023 at 02:10:54PM -0800, Erich Eickmeyer wrote: </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">Hi Lukasz, </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">I'm a bit taken-aback by the "support plan" request as for 20.04 LTS and 22.04 LTS this was never requested, and so as far as I know we would have to start from scratch. Since I'm basically on the technical side for two flavors now, I have to wear both those hats and come up with that policy for both. Unfortunately, this wording for "support plan" is too vague and needs to be more specific. </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> Guidelines for Tech Board to designate flavor image as LTS * Flavor's support plan presented to Tech Board and approved; support plan should indicate period of time if beyond 18months (3yrs or 5yr), key contacts, and setting expectations as to level of support. <a class="moz-txt-link-freetext" href="https://wiki.ubuntu.com/RecognizedFlavors?action=recall&rev=5">https://wiki.ubuntu.com/RecognizedFlavors?action=recall&rev=5</a> This has been documented since 2011 as the standard to which flavors are expected to be held. If previously the Technical Board has been lax in requiring this, that is not binding on the TB now. The flavor communities for official Ubuntu flavors ARE expected to support the flavors to their users for the lifetime of the release. Rhetorically speaking, you should not be expecting to throw a release over the wall as a one-time artifact image and wash your hands of it.</pre> </blockquote> I see what you're trying to get at here and I fully agree with what you're saying, but I would like to point out that it has *never* been the norm for any flavor that I know of to "throw a release over the wall as a one-time artifact image and wash your hands of it". The IRC (and if available, Matrix) rooms are frequently visited by flavor users and the developers provide support directly to those users, at least in the case of Ubuntu Studio, Lubuntu, Xubuntu, and Kubuntu. (I'm sure most if not all other flavors have something similar but those I know for a fact.) SRUs in packages used by flavors (including flavor-specific packages) are also common. This isn't to say anything you've said is wrong here, but simply it might soften the blow to acknowledge that Ubuntu Studio *has* been supporting their releases up until now and will continue to do so. Otherwise this comes across as if you're saying "you can't *keep* giving shoddy support", when we try to give good support. (I know that's not what you're saying, for the record.) <blockquote type="cite" cite="mid:ZWAuVb3LTakLGWwm@homer.dodds.net"> <pre class="moz-quote-pre" wrap="">This is all the more important for an LTS release, because LTS *means* "long-term support". If a flavor wants to have an LTS designation (and participate in point releases), they need to be accountable to the larger Ubuntu community that this actually means something. If we get this wrong for a non-LTS release, the consequences are fairly minor. The user who installs a non-LTS image of a flavor is only promised support for 9 months; they are not promised that the flavor will be supported at all as part of the next 6-monthly release. The flavor could sunset in that time and there be no metapackage they can even upgrade to. And if the flavor community fails to support their flavor for the full 9-month period, the impact on the rest of Ubuntu developers to pick up the slack is also likely to be minor. But if a flavor is an LTS release, meaning there is a public promise that it is supported for 3 or 5 years, then it needs to be clear to users what "supported" means for that flavor, and we need to be confident that the flavor community is actually in a position to deliver on that promise. With 10 distinct recognized community flavors, this is not something to be left to chance.</pre> </blockquote> ^ that. I'm assuming the need for this requirement to be strictly enforced is due to the sudden addition of two new flavors recently with a third on the horizon, and the goal is to make sure the new flavors give good support and the old flavors can proudly show the support they already give. <blockquote type="cite" cite="mid:ZWAuVb3LTakLGWwm@homer.dodds.net"> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">This just creates extra work for *volunteers* that are otherwise working jobs (e.g. myself as a stay-at-home father/tutor for my son, my wife as a full-time early childhood administrator). </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> All currently recognized flavors are welcome to participate in the 24.04 release as non-LTS flavors, with no additional requirement to document a support plan. If a flavor finds it overly onerous to *document* their LTS plans, I think it's self-evident that they also should not be *calling* themselves an LTS because they don't actually have capacity to commit to support.</pre> </blockquote> I don't believe that's what Erich was complaining about. I think he's complaining about the vagueness of the request (which you've helped clarify some here, thank you!), and the difficulty of figuring out what exactly you're asking for. (And it's possible he doesn't understand what you're asking for, as he seems to think that this task is going to be difficult, and you seem to think it's going to be easy, so something must not be getting communicated.) If it's just "hey, write down what your definition of "support" is and put it somewhere public", that sounds like an easy task to accomplish. But if it's something like "write an official document in legalese describing in detail exactly what users of your flavor can expect and what you are required to provide to those users", that's not so easy. I suspect you mean the former. (And yes, I did pick a deliberately extreme example for the latter, I'm just trying to make a point.) None of what I'm saying is official, I just see this looking like it may be about to turn into an argument of sorts and am hoping to help avoid that. I think what you're asking for is easy, what Erich thinks you're asking for isn't easy, and that this is a source of confusion. There's probably been more typing done in these three emails than would have been necessary to just write a support plan if your request is as straightforward and easy as it sounds like to me. So if we can just know what exactly you mean by "support plan", this can probably be straightened out easily. <blockquote type="cite" cite="mid:ZWAuVb3LTakLGWwm@homer.dodds.net"> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">I challenge that this technical requirement crosses the line from technical requirement into community encroachment, which is why the Community Council is CC'd on this email. </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> I have confidence that the Community Council will recognize that the LTS label, and the decision about committment of Release Team resources to point releases on behalf of flavors, is within the purview of the Release Team and the Technical Board to decide. </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">Also, do know that I see no ill-intent here as I do see good reasons for it, but I feel as though requiring extra work for volunteers when there is no precedent for something like this in the past seems like a bit of an overreach and an extremely vague request (support can mean anything from simple patches to 24/7 technical support which is a no-go). If there was precedent, then there would already be documentation for each flavor, but I believe a simple agreement for flavors to a blanket unified "support plan" would be more appropriate rather than requiring each flavor to come up with their own which would take more time and possibly definition than flavors should have to come up with. </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> We're not looking for an original essay here, we're looking for documentation of a credible and sensible plan. If you find it useful to coordinate with other flavors to synchronize your support committments, that's fine. And there is certainly prior art. <a class="moz-txt-link-freetext" href="https://lists.ubuntu.com/archives/technical-board/2016-April/002213.html">https://lists.ubuntu.com/archives/technical-board/2016-April/002213.html</a> </pre> <fieldset class="moz-mime-attachment-header"></fieldset> </blockquote> <pre class="moz-signature" cols="72">-- Aaron Rainbolt Lubuntu Developer Matrix: @arraybolt3:matrix.org IRC: arraybolt3 on irc.libera.chat GitHub: <a class="moz-txt-link-freetext" href="https://github.com/ArrayBolt3">https://github.com/ArrayBolt3</a></pre> </body> </html>