On Mon, Nov 29, 2021 at 05:45:46AM +0100, Kevin Kofler via devel wrote:
I also find it interesting that QA has no problems with there being 3
different options for initial setup (GNOME Initial Setup, Anaconda Initial
Setup, or doing it all during the Anaconda installation), but having a
second option for the installer (Calamares) was deemed unacceptable for
official Spins according to you. (It never went to a formal
approval/disapproval vote because no SIG actually wanted to attempt this to
begin with, not even the KDE SIG, but you have made it clear more than once
that QA would be very unhappy with the idea.)
Since QA puts a lot of work on making sure we can ship on time with KDE as a
release-blocking artifact, sure, that input carries a lot of weight. But I
don't think it necessarily blocks it, as long as the KDE SIG would
a) come up with the necessary QA time and effort so that the QA team's
overall work wouldn't be impacted -- and the same around docs and user
support (eg. on Ask Fedora and other places, where dealing with
problems with _one_ installer is definitely complicated enough)
b) separate that deliverable from the release-blocking process, because
even with (a), it's a _lot_ of stress for the QA and rel-eng team even
if they're nominally not responsible.
I kinda get the impression that "special sauce" is only
allowed if
Workstation wants it (e.g., they managed to weaken even the core Freedom
It absolutely was part of the Fedora.next plan that we'd have more autonomy
specifically for the Workstation, Cloud, and Server Working Groups. I think
that's worked pretty well, and I'd like to (and have said so to FESCo) offer
more of the same to SIGs.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader