deprecating flavors

Tue May 29 21:54:53 UTC 2018

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/
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/20180529/7ea5c4a4/attachment.sig>