"Support Plan" request challenge (WAS: Ubuntu Studio LTS Re-Qualification)

Fri Nov 24 05:02:13 UTC 2023

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.

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.

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

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                   https://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/technical-board/attachments/20231123/9afac237/attachment-0001.sig>