On 2024-01-30 05:45, Stephen Gallagher wrote:
One additional point I forgot to address: the initial concern was that
the KDE SIG would be implicitly responsible for maintaining these
packages if they are included in the main repository. From a purely
technical perspective, I think that we should state clearly that the
KDE SIG would be required only to provide advance notice of major
changes but would NOT be responsible for ensuring that these packages
adapt to them. Of course, communicating that to users is harder (and
they'll naturally report bugs to the wrong place in many cases), but I
think the KDE SIG is completely permitted to refuse and retarget any
issues that come up to the appropriate group.
I think this is a case where it's more useful to focus on technical
details than grand philosophy.
So, let's game out what might actually happen here. Say these packages
are accepted, and we have, to simplify, a large blob of packages
maintained by the KDE SIG that represents "Plasma on Wayland, supported
by the KDE SIG, release blocking" - henceforth "PLASMA-WAYLAND" - and a
small blob of packages maintained by other folks that represents "Plasma
on X.org, not supported by the SIG, not release blocking" - henceforth
PLASMA-XORG.
If I'm correct, the situation would be this:
* PLASMA-XORG would depend on PLASMA-WAYLAND, but not vice versa
* Updates to PLASMA-WAYLAND could break PLASMA-XORG, but not vice versa
* PLASMA-XORG could not block any releases
* PLASMA-XORG would not gate any updates. This is because only openQA
tests gate Plasma updates, and openQA only tests the default Plasma
configuration, Plasma-on-Wayland
Given all of this...I am not sure there is really a problem for the
Plasma SIG beyond expectations they are choosing to place on themselves.
To put it brutally, they *could* choose to just create and ship
PLASMA-WAYLAND updates and tell the PLASMA-XORG maintainers to deal with
it. No procedures or processes would stop them doing this. There would
be no release-blocking bugs, and no update gating, so long as
PLASMA-WAYLAND itself worked.
The sole exception I can think of would be if enough people filed
negative karma due to X.org failures to derail an update, but negative
karma restrictions are really pretty loose in Fedora. Karma more or less
does not affect Rawhide updates (except possibly in one rather specific
case, I am coincidentally in the middle of figuring this out). For
non-Rawhide updates, the "auto-unpush" threshold is completely
configurable, you can set it to -100 if you like. A single negative
karma disables autopush, but it doesn't force it off: you can turn it
back on. You only need a net +2, in the worst case, to push an update
stable manually.
So I would argue in favour of accepting the packages, because I don't
think the negative impact the SIG is worried about is really that
significant. I don't think they really are "forced to maintain" the Xorg
packages. I think it will prove to be practical for them to just
maintain the Wayland stack and leave maintaining the Xorg packages to
those who volunteer to do it. They can *choose* to co-ordinate
megaupdates with those maintainers if they like, but I don't think any
distro rule or mechanism will *require* it, in practice.
I also think that, in practice, things will turn out to be manageable in
a much nicer fashion. The folks who are volunteering to maintain the
X.org packages are longstanding and responsible Fedora maintainers who
are capable of doing it.
If problems do emerge after trying this in good faith for a while, it's
always possible to re-evaluate.
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@xxxxxxxxxxxxx
https://www.happyassassin.net
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
