On 11/23/23 21: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.
Terribly sorry, but in my six years of being release manager for Ubuntu
Studio (as of 24.04) we have not once been asked this question, so we
should not have to suffer this now. As such, we have nothing to work
from, especially from my tenure. That's certainly not our fault either
and we shouldn't be punished for the failures of TBs prior, so this
should not be binding on us.
> setting expectations as to level of support
This is too vague and needs to be better defined, and that's really what
I'm asking here. This is the responsibility of the TB to define, not the
flavors, since this is not the flavors' policy but the TB's policy.
> This has been documented since 2011 as the standard to which flavors
are expected to be held.
If I took that approach in my leadership of Ubuntu Studio, it probably
wouldn't exist today, especially in its current form. I would never have
had the team explore other desktop environments, and we certainly
wouldn't be working on the advances in implementing PipeWire. A 12
(almost 13!) year-old policy should be revisited and should probably be
more collaborative as opposed to unilaterally imposed. I'm certain the
flavors didn't agree to this, and now that the Flavor Sync meetings
exist, I think it would be better worked on in collaboration with the
flavor leads. I've been quoted as saying, "Just because something has
worked in the past doesn't mean it will continue to work forever."
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.
That's not what I'm suggesting.
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.
Ubuntu Studio has successfully released two LTS images under my watch
without this requirement, so I don't understand why this needs to be
revisited under a microscope now, following paragraphs nonwithstanding.
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 seems more like a lack of trust to me, which flies against the
spirit of Ubuntu, but that's just how I feel about it. From Ubuntu
Studio's perspective, I'm so far the longest tenured flavor lead, and
I'm not going anywhere as far as I can see. However, I know what burned
out the other leads, and it was stuff like this. Hence, I'm calling on
the Community Council*before* it becomes a problem, if it isn't already.
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.
The Community Council also must recognize when there are conflicts
within the community that make it unhealthy, and if the Technical Board
is imposing full-time work on any flavor team, than it crosses the line.
Where I'm at is that I'm uncomfortable with the vagueness of the request
and wish it to be defined more clearly. Flavor teams should *not* have
to come up with this on their own.
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
That's wonderful, and for the first time I have an example! Thank you!
Why didn't anyone bring this to my attention before? That said, this
seems way too detailed for a repeated LTS. I will certainly follow this
for Edubuntu since it's returning after 10 years, but for Ubuntu Studio,
and any other flavor with a prior LTS in the past two years, this should
be a much lower bar.
That said, I'm not standing-down from this challenge, but revising it: I
challenge the Technical Board to revisit and more clearly define exactly
what "Flavor's support plan presented to Tech Board and approved;
support planshould indicate period of time if beyond 18 months (3yrs or
5yr), keycontacts, and setting expectations as to level of support."
means with specifics, as the wording is too vague. Furthermore, the
policy wording is clearly outdated ("18 months"), has been around too
long without revision (2011) and the policy itself should probably be
reworked in collaboration with the Flavor Leads as is the spirit of Ubuntu.
--
Project Leader - Ubuntu Studio
Technical Lead - Edubuntu
--
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
