Re: [ubuntu-studio-devel] "Support Plan" request challenge (WAS: Ubuntu Studio LTS Re-Qualification)
On 11/24/23 21:41, Steve Langasek wrote: On Fri, Nov 24, 2023 at 12:20:53AM -0600, Aaron Rainbolt wrote: SRUs in packages used by flavors (including flavor-specific packages) are also common. Speaking as a member of the SRU Team as well, I don't actually see evidence of this. There has been a run of SRUs right at the time of the mantic release, related to release upgrades; and there was also a recent Lubuntu SRU to lunar to fix *notifications* for release upgrades; but I can't think of any other examples in the past few years. This might be because it happened that all of them were processed by other members of the SRU Team, but that's statistically unlikely. From my perspective, SRUs of core packages in main are much more common. Can you point to something I've missed showing that flavor package SRUs are happening? There are at least two high-profile fixes done in Lubuntu 22.04 via SRU, both of which were accepted by Chris Halse Rogers (RAOF). There was a Calamares version update done via SRU in Lubuntu 22.04: https://bugs.launchpad.net/ubuntu/+source/calamares/+bug/1992507 There was an SRU for a highly problematic updater bug for Lubuntu 22.04 that resulted in freezes when running updates and update notices not appearing anymore after an interrupted update (not do-release-upgrades, just normal package updates): https://bugs.launchpad.net/ubuntu/+source/lubuntu-update-notifier/+bug/2002255 tjaalton also helped out with an SRU for an updater problem when packages were to be removed: https://bugs.launchpad.net/ubuntu/+source/lubuntu-update-notifier/+bug/2012823 Together with the two SRUs you noted, this is at least *five* bugfixes pushed through by the Lubuntu team into the LTS over a year-and-a-half period, to keep the LTS working well for our end-users.(There may be even more I'm not aware of or don't remember, the ones I listed are just ones that were easy for me to remember and/or find.) We also maintain a Backports PPA for newer versions on LXQt for 22.04, which can be enabled by users manually via add-apt-repository (it's not enabled by default and never will be per TB policy). This involves backporting the entire LXQt stack to Jammy to help our users have a better experience with the LTS if they have to use the LTS and don't want to use interim releases. Ubuntu Studio has a similar Backports repository delivered via a PPA for some of the software it ships. Kubuntu also has something similar for newer versions of KDE on 22.04. These are non-trivial to implement and take a significant amount of work to make sure that our users have what they need and want in the LTS. I would consider this a form of support, and while I don't believe such repositories should be necessary to qualify for LTS status, it should be noted that it's something we do. We put a lot of effort into keeping the LTS releases working well. Aaron (I think this is very relevant to the question of LTS qualification, because demonstrating a track record of active maintenance of the stable release of a flavor goes a long way to establishing that the flavor team is delivering something that meets users' needs for an LTS.) -- 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
Re: [ubuntu-studio-devel] "Support Plan" request challenge (WAS: Ubuntu Studio LTS Re-Qualification)
Speaking as a user for some time, on multiple systems, of Ubuntu Studio, I can attest that the 20.04 version was extremely stable during the time I used it. I am currently using for somewhat different purposes Xubuntu 22.04, and this has been a bit less stable for me than Studio 20.04. I'm continuing to use it, but I've run into some minor issues that seem to have been taken care of by updates. The difference between that and Studio is that I didn't run into that kind of problem with Studio. Experience - ignore this portion unless it's useful I used Ubuntu Studio on three workstations and two laptops, most of the time using 20.04. I switched to Xubuntu since moving to a new window manager was a bit much for me at this time. Two workstations dual boot LINUX and MS Windows 10 x64; my wife uses it professionally as a psychologist and we both use it to play a game with friends. My first computer was an IBM 740 terminal connected to the Caltech 7040/7090 number cruncher; my first personal computer was an IMSAI 8080/ADM5 combination used primarily for text processing. My experience with UNIX is a bit weird; I started with a Tandy 16B about 40 years ago running XENIX-68K which eventually supported an online archive of "netnews", especially mod.sources (to the extent that Telebit and USR modems can be considered to be "online"). That system eventually moved to Open Desktop and then to Microport before being retired. I decided to retread and bought a Sun 4/110 workstation and used that, plus the XENIX experience, to get a job at the Indiana University Computer Science department as their PC specialist (my job before that time used MS-DOS). The principal job was to assist staff with using PC's in a UNIX (SunOS/IRIS) environment which eventually resulted in the department purchasing a license of an MS Windows based XWindows package for secretarial staff to use for documents written in TeX. At IU I learned about 386BSD and have used that, and it's versions, since its release. My home server currently uses FreeBSD v 13, mainly due to its familiarity. At work I continued to use MS Windows in its various versions until retirement. After retirement I decided to start migrating clients to Ubuntu, especially Studio, since we have 2 or 3 desktops and 2 laptops and licensing costs were prohibitive once I left the university. My other hobby is recording and performing live music which accounts for the interest in Studio. Thanks for the work. Mike Squires -- Michael L. Squires, Ph.D., M.P.A. michael.leslie.squi...@gmail.com Member, Bloomington Friends Meeting (Quaker) Member, Board of Directors, Arts Alliance Known in the SCA as Alan Culross, KSCA, OP, CB, etc. "Michael Leslie Squires" on Facebook Web: www.siralan.org UN*X at home since 1986 - ..!ncoast!sir-alan!mikes 812-369-5232 (cell) 812-333-6564 (home) -- 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
Re: [ubuntu-studio-devel] "Support Plan" request challenge (WAS: Ubuntu Studio LTS Re-Qualification)
On Fri, Nov 24, 2023 at 12:20:53AM -0600, Aaron Rainbolt wrote: > SRUs in packages used by flavors (including flavor-specific packages) are > also common. Speaking as a member of the SRU Team as well, I don't actually see evidence of this. There has been a run of SRUs right at the time of the mantic release, related to release upgrades; and there was also a recent Lubuntu SRU to lunar to fix *notifications* for release upgrades; but I can't think of any other examples in the past few years. This might be because it happened that all of them were processed by other members of the SRU Team, but that's statistically unlikely. From my perspective, SRUs of core packages in main are much more common. Can you point to something I've missed showing that flavor package SRUs are happening? (I think this is very relevant to the question of LTS qualification, because demonstrating a track record of active maintenance of the stable release of a flavor goes a long way to establishing that the flavor team is delivering something that meets users' needs for an LTS.) -- 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/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- 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
Re: [ubuntu-studio-devel] "Support Plan" request challenge (WAS: Ubuntu Studio LTS Re-Qualification)
Hey Erich,
I'm a relatively new member of the TB and not familiar with how flavors
were granted LTS status in the past but let me share my perspective on
what you wrote.
Le 24/11/2023 à 07:02, Erich Eickmeyer a écrit :
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.
Checking
https://lists.ubuntu.com/archives/technical-board/2016-April/002213.html
what I see in this example is 7 bullet points and less than 20 lines of
text (wrapped at 80chars), that doesn't seem a long or unachievable task
to me. Could you be a specifics on what exactly is making the bar too
high in your opinion?
To me it feels like it would have taken you less time to write those
details than those emails...
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.
The page could be probably be a bit more specific on what is asked
indeed. I think it's a fair ask for the TB to review the current wording
and policy and see if we believe changes are needed. We do review
mailing list activity and open questions during our IRC meetings so we
should be able to pick it up next time
Cheers,
Sébastien Bacher
--
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
Re: [ubuntu-studio-devel] "Support Plan" request challenge (WAS: Ubuntu Studio LTS Re-Qualification)
Hi Seb,
On 11/24/23 06:40, Sebastien Bacher wrote:
Hey Erich,
I'm a relatively new member of the TB and not familiar with how
flavors were granted LTS status in the past but let me share my
perspective on what you wrote.
Le 24/11/2023 à 07:02, Erich Eickmeyer a écrit :
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.
Checking
https://lists.ubuntu.com/archives/technical-board/2016-April/002213.html
what I see in this example is 7 bullet points and less than 20 lines
of text (wrapped at 80chars), that doesn't seem a long or unachievable
task to me. Could you be a specifics on what exactly is making the bar
too high in your opinion?
To me it feels like it would have taken you less time to write those
details than those emails...
I wasn't made aware of that email until Steve's reply, so I had no
example to work from. Furthermore, this wasn't just about me as this
affects all flavors. I've spoken to others who have been blindsided by
this requirement that have been release managers for their respective
flavors for as long as I have.
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.
The page could be probably be a bit more specific on what is asked
indeed. I think it's a fair ask for the TB to review the current
wording and policy and see if we believe changes are needed. We do
review mailing list activity and open questions during our IRC
meetings so we should be able to pick it up next time
This is essentially what I was looking for, but since I get ignored so
often on these matters, I felt it needed further attention. And, indeed,
it does affect volunteerism. While I do have a technical mind, I'm
trained in the ways of supporting volunteers and I bleed community, so I
will do whatever it takes to protect volunteers, not simply including
myself.
With that, I thank you for the consideration on this matter.
--
Erich Eickmeyer
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
Re: [ubuntu-studio-devel] "Support Plan" request challenge (WAS: Ubuntu Studio LTS Re-Qualification)
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=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
Re: [ubuntu-studio-devel] "Support Plan" request challenge (WAS: Ubuntu Studio LTS Re-Qualification)
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=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
Re: [ubuntu-studio-devel] "Support Plan" request challenge (WAS: Ubuntu Studio LTS Re-Qualification)
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=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/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or
Re: [ubuntu-studio-devel] "Support Plan" request challenge (WAS: Ubuntu Studio LTS Re-Qualification)
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. At first, I was simply going to request more specifics, but the more I thought about it (and took several hours to do so), the more I realized this is extra burden for volunteers that shouldn't be, and for that reason I'm challenging this request. In the past, as far as I can find, there has been no precedent for anything like this, and I have yet to see any member of the Technical Board justify this move as it has never been requested before and I have no evidence of a prior request for this. It should not be up to the flavors to define a "support plan" further than what has been set as precedent in the past. 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). 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. Please know, this is not an escalation for a Code of Conduct violation as, contrary to popular belief, the Code of Conduct is not the only responsibility of the Community Council, but also overall community health and oversight. I believe this situation amounts to a community health issue. I say this as a Community Council emeritus. I feel like this move is one where the Technical Board, of which I note every member is a Canonical employee, is looking at it through the lens of people who are paid to work on Ubuntu and not as volunteer leaders, something in which I have expert experience and hold a college degree and am happy to advise on. I have even offered my knowledge on this matter several times in the past and been ignored, but that's another matter entirely. However, because I've been ignored in the past on other matters, that's why I feel Community Council involvement is appropriate. 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. Thank you for understanding, and I hope we can come up with a solution. Sincerely, Erich Eickmeyer On 11/23/23 09:53, Lukasz Zemczak wrote: Hello Erich! I will be handling your LTS re-qualification from the TB side for Ubuntu Studio. Thank you for providing information about your team and contacts, as well as regarding the length of the LTS support. I think we almost have everything to make a decision here. Per the requirements listed here [1], the only thing missing from the 'support plan' POV would be setting the expectations regarding the level of support Ubuntu Studio would provide for the 3 years. Could we have like a wiki page or a page on ubuntustudio outlining this? And mentioning the support contacts and where to file bugs. Thanks! Cheers, On Mon, 13 Nov 2023 at 17:16, Erich Eickmeyer wrote: Good morning Technical Board, On behalf of Ubuntu Studio, we'd like to re-qualifiy for LTS for 3 years for 24.04. Our team ishttps://launchpad.net/~ubuntustudio-dev and I am the primary contact with rosco2 as backup. Thanks, Erich -- Erich Eickmeyer Project Leader - Ubuntu Studio Technical Lead - Edubuntu -- technical-board mailing list technical-bo...@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board On behalf of the Technical Board, -- 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
