[ubuntu-studio-devel] "Support Plan" request challenge (WAS: Ubuntu Studio LTS Re-Qualification)

Fri Nov 24 06:20:53 UTC 2023

On 11/23/23 23:02, Steve Langasek wrote:
> On Thu, Nov 23, 2023 at 02:10:54PM -0800, Erich Eickmeyer wrote:
>> Hi Lukasz,
>> 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.
>    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.
>
> https://wiki.ubuntu.com/RecognizedFlavors?action=recall&rev=5
>
> 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.

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.)

> 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.
^ 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.
>> 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).
> 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.

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.

>> 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.
> 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.
>
>> 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.
> 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.
>
> https://lists.ubuntu.com/archives/technical-board/2016-April/002213.html
>
>
-- 
Aaron Rainbolt
Lubuntu Developer
Matrix: @arraybolt3:matrix.org
IRC: arraybolt3 on irc.libera.chat
GitHub:https://github.com/ArrayBolt3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-studio-devel/attachments/20231124/d33ef3cc/attachment.html>