Hi Walter, Thanks for raising this question. While we want community flavors to be able to participate fully in the Ubuntu release cycle, including the opportunity to do long-term support releases, it has been an ongoing concern of mine on the TB that there's little accountability to the broader project regarding the upholding of the LTS promises.
We have discussed that a requirement for flavors to re-up their LTS status should be that we can demonstrate that the flavor is not significantly more insecure than Ubuntu itself due to failure to adequately handle flavor-specific CVEs. Unfortunately, I think the task of gathering that information may have fallen off the radar; and it definitely wasn't part of the review for 18.04. The point you bring up about flavors that are NOT re-upping because they are no longer committed, but also have no one following through on committments for the existing stable release, is another important one. On Mon, May 28, 2018 at 10:36:14PM -0700, Walter Lapchynski wrote: > Hey folks. I already brought [this topic][1] up on our Ubuntu Discourse > instance, but wanted to reiterate it here as I believe that this is > ultimately a decision for the Technical Board. > We have 3 flavors right now that are deprecated and inactive for > development, but according to the release notes, they’re still supported > until April 2019: > * Edubuntu Trusty Tahr > * Mythbuntu Xenial Xerus > * Ubuntu GNOME Xenial Xerus > The issue is that there remains misleading information that could be > particularly problematic for users: > * all list support methods which do not exist (the mailing lists are it > and I'm not even sure that's a reliable methodology) What support methods are listed, and where? Is this something that could be addressed by updating webpages, etc. to direct to common Ubuntu community support methods? FWIW I do not consider providing dedicated user support to be part of what a flavor is signing up for when they declare an LTS. > * the release notes do not provide next steps (even though they are > sometimes documented elsewhere) for upgrades after support ends I agree this is a problem. To be clear, is this something you would expect to find added to the release notes for the last supported release, or for the first unsupported release? Either way, it seems appropriate to ask this be done by the flavor maintainers as part of the sunsetting process, with the understanding that this won't always be possible - in some cases there simply won't be anyone left on the flavor team who is in a position to do this work. Should the default here be that we simply declare that upgrades are not supported? If we're doing a good job of gardening the Ubuntu archive, then key packages required for the system to work for the intended purpose of the flavor are likely to be missing. (mythbuntu-meta, for example, is not present in supported releases beyond xenial. edubuntu-meta is, which might signal something about whether it's meant to be supported for upgrades despite not having supported install media; OTOH the post-trusty seed maintenance has been done by non-edubuntu folks.) If someone cares about validating the upgrade path for the metapackages despite not being a recognized flavor in the next release, they can provide such information to the community; but defaulting to "upgrades not supported for this flavor" would avoid leading users down the garden path, while simultaneously minimizing the amount of extra work we have to ask for from either a flavor team which no longer has the time to maintain the flavor, or from Ubuntu community members who have no attachment to the flavor. In the specific case of Ubuntu GNOME, my understanding is that this is supported for upgrades; it has merged into Ubuntu Desktop because it's no longer seen as valuable to identify this as a distinct flavor now that the Ubuntu Desktop is again GNOME-based, not due to a lack of volunteers to maintain the Ubuntu GNOME flavor. > * for the latter two, there's no clear plan on implementing the final > point release With my ubuntu-release hat on, I have never considered point release participation a requirement for LTS flavors. Updated install media is an optimization, not a requirement, and we have had LTS flavors opt out of point releases in the past. > I think these issues illustrate a problem that we have: while we have a > great process for integrating a new flavor, we have no process set in > place to allow a flavor to step down considerately. > You can see the discussion hasn't got very far, so I don't know that I > have much to contribute to it, but I would suggest that we have a > user-centric process of some kind that ensures clear access to > information. > I know you are facing the changing of the guard for the Technical Board, > so perhaps it's best to delay this until that change happens, but I > wanted to at least get it on the table. Thanks! > [1]: https://community.ubuntu.com/t/support-for-deprecated-flavors/6191 For my part, I'm happy to engage with this topic through the duration of my term, and hand off to the next TB as necessary. In terms of outcomes from this discussion, it seems to me we want: - updates to https://wiki.ubuntu.com/RecognizedFlavors to document the sunsetting process - following up with the named flavors to make sure they are properly sunsetted according to this policy Does that sound correct to you? Do you want to propose language for the process that the TB could ratify, or do want us to drive the drafting? -- 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/ [email protected] [email protected]
signature.asc
Description: PGP signature
-- technical-board mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/technical-board
