Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux