Ubuntu Unity participation in LTS

[Steve Langasek]

Hi Rudra,

Thanks for reaching out on this.

On Thu, Nov 23, 2023 at 07:21:55PM +0530, Rudra Saraswat wrote:
> Hi,

> Speaking on behalf of Ubuntu Unity, we would like to take part in the
> upcoming 24.04 LTS.

> Here are the Ubuntu wiki pages for both points of contact:

> https://wiki.ubuntu.com/rs2009
> https://wiki.ubuntu.com/Maik

Per https://wiki.ubuntu.com/RecognizedFlavors the criteria for LTS
participation are:

 * Align with Ubuntu LTS release cycle.

   -> 24.04 of course is an LTS for Ubuntu.

 * Must have a proven track record of participating in at least 2 non-LTS
   releases before applying to TechnicalBoard for LTS designation.

   -> 23.04 and 23.10 on https://cdimage.ubuntu.com/ubuntu-unity/releases/ 

 * Flavor's support plan presented to Tech Board and approved; support plan
   should indicate period of time if beyond 18 months (3 yrs or 5 yr), key
   contacts, and setting expectations as to level of support.

   -> How long are you proposing that Ubuntu Unity's LTS support cycle be: 3
      or 5 years?  You've addressed the "contacts" point above; you are
      reachable on IRC, your wiki page lists your email, and although Maik
      does not appear to be on IRC his wiki page lists an email address. 
      Please also address the question of your plans around the support you
      will provide (as for example
      https://lists.ubuntu.com/archives/technical-board/2023-November/002786.html).

  * Support plan public and ongoing support contacts accessible for
    discussion of bugs and security issues (or alternates designated)
    through life of project.

    -> Once agreed, ideally this information will go on a webpage somewhere
       rather than just being in the mailing list archive; such as under
       https://ubuntuunity.org or on https://wiki.ubuntu.com.

  * Key Upstream packages worth supporting for extended cycle.

    -> Since Canonical is no longer the upstream for Unity, do you consider
       yourself the upstream now for the unity packages?  I see that
       debian/control for the unity source package still points to
       https://launchpad.net/unity, but this is owned by ~unity-team which
       has only ubuntu-core-dev and Canonical employees as members.  The
       latest unity package has an upstream version number of
       '7.7.0+23.04.20230222.2' but there is no corresponding .orig.tar.xz
       as part of the source, this is a native package; the debian/watch
       file also points back at https://launchpad.net/unity, which has 7.4.0
       as its latest release tarball.  So it is entirely unclear to me what
       the version number in this package is meant to indicate.

       Other "unity" packages that are seeded:
       - unity-greeter: there's been an upload in the past 6 months, but by
         a member of the Ubuntu Desktop Team? unclear to me what's happening
         here or, again, what the bump in the upstream version number is
         supposed to mean (also, a native package). 
       - unity-setting-daemon: no upstream release since 2015, no uploads
         since 2022 (including a no-change rebuild that bumped the upstream
         part of the package version number?!)
       - unity-control-center: similar to unity; package activity is clearly
         handled by Ubuntu Unity team, but upstream repository references
         point to places not under your control.  (Also, debian/copyright is
         hilariously wrong...)
       - libunity (for unity-scopes-runner): no uploads since 2019.  Repo
         owned by ~unity-team.
       - unity-lens-appliactions: no upstream release since 2016, no uploads
         since 2020.
       - unity-lens-files: no upstream release since 2017, no uploads since
         2018.
       - unity-indicator-appearance: you are evidently the maintainer.  One
         upload ever (kinetic).  No bugs reported ever...
         https://bugs.launchpad.net/ubuntu/+source/unity-indicator-appearance

       I think it's clear that the desktop environment in Ubuntu Unity is
       strictly in "maintenance mode"; that's fine, and does not preclude
       participation in an LTS, as the firm expectation is that in an LTS
       all of the underpinnings (kernel, libdrm, mesa, X, Wayland) will
       provide stable interfaces that do not present a problem for
       maintenance of a DE with little upstream capacity.  However, I think
       the state of these projects with respect to even *having* an
       identifiable, non-moribund upstream is concerning.  If a researcher
       finds a security vulnerability in one of these packages, will they
       even know where to report it?  I guess they might just report it to
       security at ubuntu.com, since they must have been investigating the
       Ubuntu packages anyway.  Is that sufficient?

       Would it make sense to clean up the state of the upstream projects in
       launchpad, that are pointed to from the source packages, to make
       ownership by the unity7 team clear?


  * Written confirmation from IS that space and resources are available to
    retain images in archive through LTS life cycle.

    -> Note that I intend to address this with Canonical IS on behalf of the
       Release Team centrally for all flavors.  While it is still correct to
       have this as an explicit checklist item, this predates Canonical's
       migration to cloud-based infrastructure internally with elastic
       storage: we still want to make sure flavors aren't producing large
       artifacts that are going to impose an unreasonable storage cost on
       Canonical, but we don't have hard limits any more based on the size
       of fixed disks in our web frontends and I don't expect there to be
       any issues here in practice.

Thanks,
-- 
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/20231124/a0cb9cc1/attachment-0001.sig>