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 secur...@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/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
-- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
