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
--
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
