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

[Sérgio Basto]

Link to the FESCo ticket: https://pagure.io/fesco/issue/3165

and I'm very upset 
 
-- 
Sérgio M. B.

[Germano Massullo]

What does it mean that FESCo is applying an injunction?

[Marc Deop i Argemí]

On Tuesday, 30 January 2024 14:04:29 CET Germano Massullo wrote:
>  What does it mean that FESCo is applying an injunction? 
Only that the packages in question are "on hold" until a decision can be 
taken.

The word sounds way worse than what it really is.

[Steve Cossette]

On 2024-01-30 8:04 a.m., Germano Massullo wrote:
>  What does it mean that FESCo is applying an injunction?
>
>  --
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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/[e-mail]
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
An injunction is a hold. Not blocking it outright, just holding it back 
until we're done discussing this.

[Richard W.M. Jones]

On Tue, Jan 30, 2024 at 12:47:44PM +0000, Sérgio Basto wrote:
>  Link to the FESCo ticket: https://pagure.io/fesco/issue/3165
>  
>  and I'm very upset  
Assume best intent first of all.  An injunction is a temporary thing
to allow some space for a decision to be made.

(I added my personal opinion to the ticket itself)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW

[Stephen Gallagher]

On Tue, Jan 30, 2024 at 8:07 AM Richard W.M. Jones <rjones(a)redhat.com&gt; wrote:
>  On Tue, Jan 30, 2024 at 12:47:44PM +0000, Sérgio Basto wrote:
>  > Link to the FESCo ticket: https://pagure.io/fesco/issue/3165
>  >
>  > and I'm very upset
>
>  Assume best intent first of all.  An injunction is a temporary thing
>  to allow some space for a decision to be made.
>
>  (I added my personal opinion to the ticket itself)
>  
First of all, thank you for assuming best intent.

I'll apologize first for the terseness of those messages; I was in a
rush between meetings and I left out basically all of the context (and
probably used a stronger word -- injunction -- than was strictly
called for). I'm sorry for that.

Next, I'll address Kevin's comment that the "injunction" lacked a
quorum vote to enforce: you are correct. That's the whole reason for
it: the issue came up at the end of an already-long FESCo meeting and
we did not have time to discuss it in the detail it deserves. The
intent was not to make a ruling (which was impossible without quorum),
but to instead indicate that the package review should refrain from
landing until FESCo makes a determination of its suitability and
alignment with Fedora's goals. This is as much for the packagers
involved as anyone; we don't want you to be putting in effort that
FESCo might ultimately require you to revert if the decision goes that
way.

Again, I apologize for not doing a better job communicating that yesterday.


Now, as for my personal stance on the issue upon a night's reflection
(some of this is in reply to comments on
https://pagure.io/fesco/issue/3165 that I feel should be discussed in
a more public forum):

1) I agree that if a Fedora packager wants to maintain a package, then
that package should not be excluded from Fedora except under very
exceptional cases.
2) FESCo is ultimately the arbiter of what software comprises "Fedora
Linux" as made available to the rest of the world. In practice, this
mostly means the install/Live media contents as well as container and
VM images that are released as official Fedora deliverables.
3) Fedora has a long-standing and well-communicated stance that we are
a Wayland distribution first and foremost and that X11 support is
intended as a migration-support tool rather than a first-class
citizen.
4) There was a comment on the FESCo ticket to the effect of '"you must
move to Wayland because no one maintains X11!". Here are some people
who are maintaining X11 packages, so let them do their thing.' This is
misleading, as the move to Wayland is specifically because the
upstream of X11 *itself* is largely unmaintained. These packages are
not maintaining X11, they are adding new dependencies on it.

My proposal for consideration is this:
"FESCo will allow these packages in the main Fedora repositories,
however they may not be included by default on any release-blocking
deliverable (ISO, image, etc.)"

[Stephen Gallagher]

On Tue, Jan 30, 2024 at 8:38 AM Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:
>  On Tue, Jan 30, 2024 at 8:07 AM Richard W.M. Jones <rjones(a)redhat.com&gt; wrote:
>  >
>  > On Tue, Jan 30, 2024 at 12:47:44PM +0000, Sérgio Basto wrote:
>  > > Link to the FESCo ticket: https://pagure.io/fesco/issue/3165
>  > >
>  > > and I'm very upset
>  >
>  > Assume best intent first of all.  An injunction is a temporary thing
>  > to allow some space for a decision to be made.
>  >
>  > (I added my personal opinion to the ticket itself)
>  >
>
>  First of all, thank you for assuming best intent.
>
>  I'll apologize first for the terseness of those messages; I was in a
>  rush between meetings and I left out basically all of the context (and
>  probably used a stronger word -- injunction -- than was strictly
>  called for). I'm sorry for that.
>
>  Next, I'll address Kevin's comment that the "injunction" lacked a
>  quorum vote to enforce: you are correct. That's the whole reason for
>  it: the issue came up at the end of an already-long FESCo meeting and
>  we did not have time to discuss it in the detail it deserves. The
>  intent was not to make a ruling (which was impossible without quorum),
>  but to instead indicate that the package review should refrain from
>  landing until FESCo makes a determination of its suitability and
>  alignment with Fedora's goals. This is as much for the packagers
>  involved as anyone; we don't want you to be putting in effort that
>  FESCo might ultimately require you to revert if the decision goes that
>  way.
>
>  Again, I apologize for not doing a better job communicating that yesterday.
>
>
>  Now, as for my personal stance on the issue upon a night's reflection
>  (some of this is in reply to comments on
>  https://pagure.io/fesco/issue/3165 that I feel should be discussed in
>  a more public forum):
>
>  1) I agree that if a Fedora packager wants to maintain a package, then
>  that package should not be excluded from Fedora except under very
>  exceptional cases.
>  2) FESCo is ultimately the arbiter of what software comprises "Fedora
>  Linux" as made available to the rest of the world. In practice, this
>  mostly means the install/Live media contents as well as container and
>  VM images that are released as official Fedora deliverables.
>  3) Fedora has a long-standing and well-communicated stance that we are
>  a Wayland distribution first and foremost and that X11 support is
>  intended as a migration-support tool rather than a first-class
>  citizen.
>  4) There was a comment on the FESCo ticket to the effect of '"you must
>  move to Wayland because no one maintains X11!". Here are some people
>  who are maintaining X11 packages, so let them do their thing.' This is
>  misleading, as the move to Wayland is specifically because the
>  upstream of X11 *itself* is largely unmaintained. These packages are
>  not maintaining X11, they are adding new dependencies on it. 
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.


>  My proposal for consideration is this:
>  "FESCo will allow these packages in the main Fedora repositories,
>  however they may not be included by default on any release-blocking
>  deliverable (ISO, image, etc.)"

[Adam Williamson]

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(a)fosstodon.org
https://www.happyassassin.net

[Gary Buhrmaster]

On Tue, Jan 30, 2024 at 1:46 PM Stephen Gallagher <sgallagh(a)redhat.com&gt; 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 would suggest that it is entirely reasonable
that there be a threshold where if users
continually report bugs that the KDE SIG
must deal with (i.e. someone else's packages
are causing excessive overhead for the SIG,
even just to close/retarget the bugs/issues)
that they can petition that the offending
packages get suspended/removed.  I don't
know what that threshold will be, but I
suspect the SIG will know it when they see
it.  I would suggest that the packager of
those other packages monitors all new
bugs/issues and "takes" them early and
often to insure that the SIG is not unduly
burdened, and the threshold petition would
never need to be considered.

[kevin]

I've very sorry if anyone was upset by fesco wanting to not allow the
new packages in while this was discussed. I'm the one who suggested
that, but as noted upthread, the idea was simply to allow time for
discussion before doing things. 

There's actually a slightly similar case from long long ago to this one:
Fedora only allows one kernel package.
(
https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-pac...
)
The discussion at the time from what I recall was that if anyone could
add custom kernels, it would vastly increase the support burden on the
main fedora kernel maintainers. People would report bugs to 'kernel' and
ask them about it even if the package was named differently.

If Adam's summary is understood by all the involved parties, then I
don't think there would be a problem allowing the packages in.
Everyone involved should just try and not place undue burdens on others.
If there's a flood of reports or issues that take away from real
requests to the kde sig, then perhaps things should be re-evaluated.

On Tue, Jan 30, 2024 at 06:09:39PM +0000, Gary Buhrmaster wrote:
>  
>  I would suggest that it is entirely reasonable
>  that there be a threshold where if users
>  continually report bugs that the KDE SIG
>  must deal with (i.e. someone else's packages
>  are causing excessive overhead for the SIG,
>  even just to close/retarget the bugs/issues)
>  that they can petition that the offending
>  packages get suspended/removed.  I don't
>  know what that threshold will be, but I
>  suspect the SIG will know it when they see
>  it.  I would suggest that the packager of
>  those other packages monitors all new
>  bugs/issues and "takes" them early and
>  often to insure that the SIG is not unduly
>  burdened, and the threshold petition would
>  never need to be considered. 
Yeah, I agree.

kevin

[Zbigniew Jędrzejewski-Szmek]

On Tue, Jan 30, 2024 at 01:48:08PM -0800, kevin wrote:
>  If Adam's summary is understood by all the involved parties, then
> I
>  don't think there would be a problem allowing the packages in.
>  Everyone involved should just try and not place undue burdens on others.
>  If there's a flood of reports or issues that take away from real
>  requests to the kde sig, then perhaps things should be re-evaluated. 
+1 to this. (And implicitly, to what at least Stephen, Adam, and Gary
wrote before in slightly different words. It seems that we arrived at
a consensus very quickly for a relatively controversial topic.)

Zbyszek

[Zbigniew Jędrzejewski-Szmek]

On Tue, Jan 30, 2024 at 08:45:37AM -0500, 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.
>  
>  
>  > My proposal for consideration is this:
>  > "FESCo will allow these packages in the main Fedora repositories,
>  > however they may not be included by default on any release-blocking
>  > deliverable (ISO, image, etc.)" 
I think we should reword this proposal to address this point:

"FESCo will allow these packages in the main Fedora repositories,
however they may not be included by default on any release-blocking
deliverable (ISO, image, etc.). The KDE SIG should provide a notice
before major changes, but is NOT responsible for ensuring that these
packages adapt."

Zbyszek

[Stephen Gallagher]

On Wed, Jan 31, 2024 at 8:44 AM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl&gt; wrote:
>  On Tue, Jan 30, 2024 at 08:45:37AM -0500, 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.
>  >
>  >
>  > > My proposal for consideration is this:
>  > > "FESCo will allow these packages in the main Fedora repositories,
>  > > however they may not be included by default on any release-blocking
>  > > deliverable (ISO, image, etc.)"
>
>  I think we should reword this proposal to address this point:
>
>  "FESCo will allow these packages in the main Fedora repositories,
>  however they may not be included by default on any release-blocking
>  deliverable (ISO, image, etc.). The KDE SIG should provide a notice
>  before major changes, but is NOT responsible for ensuring that these
>  packages adapt." 
I can absolutely support that.

[Alessandro Astone]

I can support that.

But am I supposed to ignore the fact that kkofler is already bullying the KDE SIG into not
breaking that one other package they maintain that occasionally breaks on kde updates? See
example: https://bodhi.fedoraproject.org/updates/FEDORA-2023-977de87584

Am I going to have to see kkofler rant in every plasma update that their xorg stack
breaks?

[Mattia Verga]

-------- Messaggio originale --------
31/01/24 22:27, Alessandro Astone <ales.astone(a)gmail.com&gt; ha scritto:

>   I can support that.
>   
>   But am I supposed to ignore the fact that kkofler is already bullying the KDE SIG into
> not breaking that one other package they maintain that occasionally breaks on kde updates?
> See example: https://bodhi.fedoraproject.org/updates/FEDORA-2023-977de87584
>   
>   Am I going to have to see kkofler rant in every plasma update that their xorg stack
> breaks?
>   -- 
Firstly, let's not make personal attacks.

The reported example refers to an update submitted for a stable release, where every
effort in order to not to break things must be made. Was that happened before the side-tag
update was pushed? imo, saying "blogilo is dead upstream and you're the only one
left using it" is not enough.

Mattia

[Alessandro Astone]

The "personal attack" is a consideration on the proposed maintainer of these
packages.

>  every effort in order to not to break things must be made. 
Then I cannot support these packages being added. It is putting additional effort on the
KDE-SIG up to once per every week; especially since we're at the beginning of the
Plasma 6 release cycle and releases are going to be hectic.
The proposed resolutions by adamw, zbyszek, etc. seem to imply that it would not be
required.
blogilo is as much of a non-release-blocking component as plasma-workspace-x11 would be.

[Mattia Verga]

Il 31/01/24 23:38, Alessandro Astone ha scritto:
>  The "personal attack" is a consideration on the proposed
> maintainer of these packages.
>
> > every effort in order to not to break things must be made.
>  Then I cannot support these packages being added. It is putting additional effort on the
> KDE-SIG up to once per every week; especially since we're at the beginning of the
> Plasma 6 release cycle and releases are going to be hectic.
>  The proposed resolutions by adamw, zbyszek, etc. seem to imply that it would not be
> required.
>  blogilo is as much of a non-release-blocking component as plasma-workspace-x11 would be.
>  -- 
There I was referring to stable releases. I assume you're not going to 
rebuild and push updates into stable releases once per week.

FWIW I am an happy user of Plasma on Wayland and don't need X11. 
However, Fedora is a community project, so the fact one don't care about 
a software doesn't mean they can stop someone else packaging it, as long 
as there someone interested in doing the work. If that means delaying 
updates by one week waiting for the other maintainers to rebuild their 
packages, we must allow that, as we do for all other cases.

I am also quite sure that things would be much more simple for both 
parties if -x11 guys would make use of COPR instead of building their 
packages in distgit. That way they can choose to rebuild the kde plasma 
common stack with the epoch bumped, so that anyone using the COPR 
repository will have that packages overwrite the Fedora ones, and build 
their -x11 with their "LTS" version. That way anyone using X11 will not 
see any breakage and they can choose to upgrade the base packages when 
they want/have free time.

Mattia

[Neal Gompa]

On Thu, Feb 1, 2024 at 6:58 AM Mattia Verga via devel
<devel(a)lists.fedoraproject.org&gt; wrote:
>  Il 31/01/24 23:38, Alessandro Astone ha scritto:
>  > The "personal attack" is a consideration on the proposed maintainer of
> these packages.
>  >
>  >> every effort in order to not to break things must be made.
>  > Then I cannot support these packages being added. It is putting additional effort on
> the KDE-SIG up to once per every week; especially since we're at the beginning of the
> Plasma 6 release cycle and releases are going to be hectic.
>  > The proposed resolutions by adamw, zbyszek, etc. seem to imply that it would not be
> required.
>  > blogilo is as much of a non-release-blocking component as plasma-workspace-x11 would
> be.
>  > --
>
>  There I was referring to stable releases. I assume you're not going to
>  rebuild and push updates into stable releases once per week.
>
>  FWIW I am an happy user of Plasma on Wayland and don't need X11.
>  However, Fedora is a community project, so the fact one don't care about
>  a software doesn't mean they can stop someone else packaging it, as long
>  as there someone interested in doing the work. If that means delaying
>  updates by one week waiting for the other maintainers to rebuild their
>  packages, we must allow that, as we do for all other cases.
>
>  I am also quite sure that things would be much more simple for both
>  parties if -x11 guys would make use of COPR instead of building their
>  packages in distgit. That way they can choose to rebuild the kde plasma
>  common stack with the epoch bumped, so that anyone using the COPR
>  repository will have that packages overwrite the Fedora ones, and build
>  their -x11 with their "LTS" version. That way anyone using X11 will not
>  see any breakage and they can choose to upgrade the base packages when
>  they want/have free time.
>  
I started providing a COPR specifically for this reason a few months
ago[1], and we moved it to the KDE SIG namespace earlier this week[2].
It tracks our DistGit packages and turns back on X11 support
automatically. The KDE SIG instance of the COPR is configured with a
higher priority than the distribution packages, so they "overshadow"
them and prevent Plasma X11 from being uninstalled on upgrade by
blocking upgrades until a compatible package is available.

My position as the KDE SIG lead based on discussions within the SIG is
that re-introducing these packages in the main distribution would
destroy the main point of our efforts: driving KDE Plasma Wayland to
be the best and most complete experience. The signal of dropping
Plasma X11 largely drove a lot of improvements in Plasma 6 very
quickly that I do not believe would have otherwise occurred. The
upstream KDE developers did a lot of work for us because we
communicated priorities and worked with them very early to frame the
roadmap for the future of Plasma Wayland.

The truth is we started hitting a wall about two years ago because
with the crutch of Plasma X11, there was just simply not enough
motivation to find solutions for the remaining missing
features/capabilities. We started signaling our intent two years ago
to drop Plasma X11 with Plasma 6 at Akademy 2022, but even most of
that effort wasn't taken seriously until last year, when I reiterated
it again at Akademy there. A huge burst of feature development
occurred precisely because of the feedback from the discussion in the
Change proposal.

To put it bluntly, KDE Plasma Wayland has features and capabilities
that neither X11 nor GNOME Wayland has. There are both compatibility
modes (X11 hotkey support and alternate X11 application scaling modes)
and amazing features (VRR, fullscreen HDR, hardware accelerated screen
recording/sharing/remote desktop). The remaining gaps are being worked
on with a decent pace in a large part because Fedora KDE will only
offer Plasma Wayland. Today, there are people who consider Fedora KDE
a "premium experience"[3] and that's a tremendous credit to the team
who have worked really hard to deliver the best KDE Plasma experience
possible.

The consensus from the KDE SIG is that we believe that reintroducing
the packages into the distribution will not only unwind a major part
of the approved Change, but it will add complications for the SIG for
shipping updates to KDE Plasma on the cadence that we typically do and
we would rather the X11 packages stay in COPR.

[1]: https://copr.fedorainfracloud.org/coprs/ngompa/kde6-x11-unsupported/
[2]: https://copr.fedorainfracloud.org/coprs/g/kdesig/plasma6-x11-unsupported/
[3]:
https://www.reddit.com/r/kde/comments/1advyxe/pretty_sure_fedora_40_will_...



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Zbigniew Jędrzejewski-Szmek]

On Thu, Feb 01, 2024 at 07:51:59AM +0000, Neal Gompa wrote:
[snip]
>  My position as the KDE SIG lead based on discussions within the SIG
> is
>  that re-introducing these packages in the main distribution would
>  destroy the main point of our efforts: driving KDE Plasma Wayland to
>  be the best and most complete experience. The signal of dropping
>  Plasma X11 largely drove a lot of improvements in Plasma 6 very
>  quickly that I do not believe would have otherwise occurred. 
[snip]
>  The consensus from the KDE SIG is that we believe that reintroducing
>  the packages into the distribution will not only unwind a major part
>  of the approved Change, but it will add complications for the SIG for
>  shipping updates to KDE Plasma on the cadence that we typically do and
>  we would rather the X11 packages stay in COPR. 
All of what you wrote (in the snipped parts too) is true. But we have
to take into account that there is a bunch of people who want to work
on the alternate approach. It's their right and we shouldn't _force_
obsolescence of older software, especially if it still has users.
The sitatation with X11 is complicated: many people report that it
still works better for them (whatever the reasons may be).
So I think that it's fine to say "KDE SIG, go ahead, do your thing
without waiting for X11", but it's not fine to say "we will forbid having
KDE-X11 packages in Fedora".

Zbyszek

[Kevin Kofler]

Neal Gompa wrote:
>  My position as the KDE SIG lead based on discussions within the SIG
> is
>  that re-introducing these packages in the main distribution would
>  destroy the main point of our efforts: driving KDE Plasma Wayland to
>  be the best and most complete experience. The signal of dropping
>  Plasma X11 largely drove a lot of improvements in Plasma 6 very
>  quickly that I do not believe would have otherwise occurred. The
>  upstream KDE developers did a lot of work for us because we
>  communicated priorities and worked with them very early to frame the
>  roadmap for the future of Plasma Wayland. 
So basically you are trying to strongarm upstreams (KDE, but also third-
party application developers) into supporting Wayland by boycotting X11. 
That makes it all the funnier that you are then accusing me of trying to 
"strongarm" you "into supporting X11" (as Steve Cossette (farchord)
wrote in 
the FESCo ticket).

>  We started signaling our intent two years ago to drop Plasma X11
> with
>  Plasma 6 at Akademy 2022, but even most of that effort wasn't taken
>  seriously until last year, when I reiterated it again at Akademy there. 
I am not surprised that your announcements were not taken seriously, because 
dropping X11 sounds so unreasonable to not just me that it just cannot be 
taken seriously.

        Kevin Kofler

[Leigh Scott]

>  I can support that.
>  
>  But am I supposed to ignore the fact that kkofler is already bullying the KDE SIG into
> not
>  breaking that one other package they maintain that occasionally breaks on kde updates?
> See
>  example: https://bodhi.fedoraproject.org/updates/FEDORA-2023-977de87584
>  
>  Am I going to have to see kkofler rant in every plasma update that their xorg stack
>  breaks? 
kde users with nvidia are going to suffer if x11 is removed.
I wont be accepting any kde wayland issues filed at rpmfusion.

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jan 31, 2024 at 09:27:52PM -0000, Alessandro Astone wrote:
>  I can support that.
>  
>  But am I supposed to ignore the fact that kkofler is already bullying the KDE SIG into
> not breaking that one other package they maintain that occasionally breaks on kde updates?
> See example: https://bodhi.fedoraproject.org/updates/FEDORA-2023-977de87584
>  
>  Am I going to have to see kkofler rant in every plasma update that their xorg stack
> breaks? 
I hope not ;) Essentially, the proposed resolution say that it's OK to
ignore packages that part of the -x11 stack if they haven't been fixed
sufficiently quickly. 

On Wed, Jan 31, 2024 at 10:38:27PM -0000, Alessandro Astone wrote:
>  The "personal attack" is a consideration on the proposed
> maintainer of these packages.
>
>  > every effort in order to not to break things must be made. 
This describes the normal policy for updates. Here we are talking
about an exception: every effort DOES NOT have to be made. I assume
the maintainers will do what is reasonable, but the only strict
requirement is a "notice before major changes".

KDE is already subject an Updates Policy exception that allows major
updates in stable releases [1,2]. This will make it harder for the -x11
stack to keep up.

[1] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#kde
[2] https://fedoraproject.org/wiki/SIGs/KDE/Update_policy

>  Then I cannot support these packages being added. It is putting
>  additional effort on the KDE-SIG up to once per every week;
>  especially since we're at the beginning of the Plasma 6 release
>  cycle and releases are going to be hectic.
>  The proposed resolutions by adamw, zbyszek, etc. seem to imply that
>  it would not be required. blogilo is as much of a
>  non-release-blocking component as plasma-workspace-x11 would be. 
This all sounds like maintaining the -x11 stack will be a lot of work.
Nevertheless, with the proposed resolution, this is not _your_ problem.
It's the job of the folks who signed up to maintain the older packages
to do that.

I know that you expect that this will cause additional friction
and user confusion and slows things down. I expect that you are right.
Things would be a bit smoother if we dropped the -x11 packages
completely, but in this case, the reasons to not do that are
also important.

Firstly, Fedora is about letting people work on the stuff that they
want to work on. We can't and — I'm very certain — shouldn't prevent
people from working on the -x11 stack if they want to. By the same
token, I support your desire to not work on the -x11 and concentrate
on the wayland variants.

Secondly, there are strong benefits from having packages in the main
distro. The proposed approaches with a copr or other form of external
packages are possible, and would be OK for more advanced users, but
it's just easier and more secure for "normal" users if packages are in
the main repo. If it turns out that this approach doesn't work, we
can always move to one of the other approaches later (or abandon
the old stack completely).

Zbyszek

[Alessandro Astone]

Thank you for clarifying.

[Kevin Kofler]

Alessandro Astone wrote:
>  But am I supposed to ignore the fact that kkofler is already bullying
> the
>  KDE SIG into not breaking that one other package they maintain that
>  occasionally breaks on kde updates? See example:
>  https://bodhi.fedoraproject.org/updates/FEDORA-2023-977de87584 
To make it clear about the situation of that particular package: The KDE SIG 
never notifies me in advance about kdepim bumps. They push them to Rawhide, 
then I eventually get FTI/FTBFS reports for Blogilo filed by some automatic 
process, and then I scramble to fix Blogilo in Rawhide. If they bothered 
notifying me, it would probably get fixed sooner.

In the particular case I complained about above, they immediately proceeded 
to build the kdepim update for the current stable release without giving me 
any time to fix the breakage in Rawhide.

The nature of the upstream update was also such that the kdepim libraries 
removed/moved some APIs upstream, so this was really an incompatible library 
change, not the usual backwards-compatible change expected within a KDE 
major release. I am not sure why the upstream kdepim developers opted to 
make these changes in their KF5 versions, which should really have been in 
maintenance mode by then, instead of doing them only in the KF6 versions 
where such changes would have been expected as part of the major version 
bump. (Hence, my "yet another incompatible kdepim stack update" complaint 
was also about upstream, not only about the KDE SIG.)

The normal Fedora policy for this kind of changes is to give time for 
maintainers of dependent applications, even if they are legacy applications, 
to fix the applications before pushing the update to stable releases. In the 
Blogilo case, I do not remember having agreed to (nor having been ordered by 
FESCo to accept) anything different. I fixed Blogilo as quickly as I could 
even though it was not trivial. I am sorry for the few days of delay caused 
by that.

I do not expect the *-x11 updates to take that long, because all I normally 
need to do there is to bump Version, use the same tarball as for the Wayland 
version, and rebuild. As long as upstream maintains X11 support, I will not 
be in a situation like for Blogilo where I have to backport support for 
changed library APIs to an ancient codebase not updated anymore by upstream. 
So I do not expect the user experience to be that bad.

The one thing that would be helpful is, if I have the *-x11 packages already 
updated in Rawhide dist-git, to just sync them to the release branch and 
build them in the side tag when they prepare an update for a release. (As I 
understand it, the scripts they use to sync branches and build updates can 
probably do that with no extra human effort.) Though, if not, I can do that 
too, if only they tell me about the update and the side tag as soon as 
possible, at least before they hit that "push to stable" button.

        Kevin Kofler

[Marc Deop i Argemí]

On Friday, 2 February 2024 00:38:56 CET Kevin Kofler via devel wrote:
>  To make it clear about the situation of that particular package: The
> KDE SIG
>  never notifies me in advance about kdepim bumps. 
To make it clear about this particular package:

- we have _forgotten_ indeed to notify the maintainers on occasions.
- why did we forget? because the KDE collection is close to 400 packages and 
despite our automation, we are humans and this kind of thing happens.
- to make it clear that we *bother* (using your own words), I even submitted 
tickets upstream to help out on the situation: https://invent.kde.org/pim/
pimcommon/-/issues/2
- worth mentioning that despite the kdepim libraries being released as 
packages, they are *NOT* intended to be consumed externally but as a whole KDE 
PIM ecosystem
- this approach worked for blogilo in the past because it was part ot the KDE 
PIM ecosystem
- worth mentioning that Blogilo has been unmaintained for many years

I personally used blogilo in the past and loved the app myself.

However, sometimes we need to be pragmatic in life. I will quote one of the 
main developers of the KDE PIM:

" I don't understand why you still continue to release a dead apps from long 
time..."

Link to the *unmaintained* blogilo (not _legacy_): https://invent.kde.org/
unmaintained/blogilo

[Kevin Kofler]

Marc Deop i Argemí wrote:
>  To make it clear about this particular package:
>  
>  - we have _forgotten_ indeed to notify the maintainers on occasions.
>  - why did we forget? because the KDE collection is close to 400 packages
>  and despite our automation, we are humans and this kind of thing happens. 
This is OK. We all make mistakes.

I just wanted to explain why I was slightly upset in that update's comments. 
But I worked to rectify the situation pretty quickly, and the update went 
out, without breaking Blogilo, soon afterwards. I do not think "bullying" 
(as Alessandro Astone wrote) is a fair term to describe my intervention in 
that update.

>  - to make it clear that we *bother* (using your own words), I even
>  submitted tickets upstream to help out on the situation:
>  https://invent.kde.org/pim/pimcommon/-/issues/2 
Noted.

>  - worth mentioning that despite the kdepim libraries being released
> as
>  packages, they are *NOT* intended to be consumed externally but as a whole
>  KDE PIM ecosystem
>  - this approach worked for blogilo in the past because it was part ot the
>  KDE PIM ecosystem
>  - worth mentioning that Blogilo has been unmaintained for many years 
It is also worth mentioning that most kdepim updates since Blogilo has 
become unmaintained have not caused major issues for Blogilo. 1 or 2 recent 
ones were troublesome because some API cleanups in preparation for kdepim 6 
were also done in the KF5-based branch (an upstream decision I would 
question, though I understand their approach of just porting the 
(maintained) applications together with the libraries rather than 
maintaining strict backwards compatibility in the libraries).

>  I personally used blogilo in the past and loved the app myself.
>  
>  However, sometimes we need to be pragmatic in life. I will quote one of
>  the main developers of the KDE PIM:
>  
>  " I don't understand why you still continue to release a dead apps from
>  long time..." 
Because it is still useful (though there is at least one annoying composer 
bug where it likes to blank the composer content at times, which I should 
try to track down and fix – that bug had been introduced before Blogilo had 
become officially unmaintained, I am not sure when exactly).

>  Link to the *unmaintained* blogilo (not _legacy_):
> https://invent.kde.org/
>  unmaintained/blogilo 
I do not see a hard distinction between "legacy" and "unmaintained". 
Unmaintained applications are by definition legacy, and legacy applications 
are often either unmaintained or de-facto-unmaintained/semi-unmaintained 
(like X.Org X11). Some legacy applications are maintained, but considered 
legacy for other reasons (such as depending on unmaintained libraries, or 
implementing an obsolete technology, etc.), but that is not the typical 
case.

        Kevin Kofler

[Alessandro Astone]

Also "major changes" would be the ~fibonacci-weekly~ Plasma bugfix release, as
the -x11 package will require an exact version match of the common libraries. Not really a
rare occasion.

[Kevin Kofler]

Alessandro Astone wrote:
>  Also "major changes" would be the ~fibonacci-weekly~ Plasma
> bugfix
>  release, as the -x11 package will require an exact version match of the
>  common libraries. Not really a rare occasion. -- 
This can be solved with communication.

That said, if the KDE SIG does not want to have to coordinate changes with 
any third party, not even as far as just notifying us of the impending 
changes (Stephen Gallagher's proposal does not even require you to wait for 
me or anybody else to reply! Just to asynchronously notify me/us, i.e., drop 
a single mail to kwin-x11-owner@….), then the easy way would be to just go 
back to building those subpackages as part of the respective main package. 
I.e., let me and/or anyone else who wants Plasma on X11 comaintain the 2 
packages and assign any X11 issues to me/them. That would probably be the 
least work for everyone.

But the separate packages as I submitted them for review are the next best 
solution.

        Kevin Kofler

[Marc Deop i Argemí]

On Friday, 2 February 2024 00:49:19 CET Kevin Kofler via devel wrote:
>  This can be solved with communication.
>   
That is dealing with the situation your packages would cause, not solving it. 
( I don't mean ill will, it just a statement) 

>  That said, if the KDE SIG does not want to have to coordinate changes
> with
>  any third party, not even as far as just notifying us of the impending
>  changes (Stephen Gallagher's proposal does not even require you to wait for
>  me or anybody else to reply! Just to asynchronously notify me/us, i.e., drop
>  a single mail to kwin-x11-owner@….), 
Nobody wants having to coordinate with others, that makes any process more 
complicated and resource consuming.

>  then the easy way would be to just go
>  back to building those subpackages as part of the respective main package. 
That is the easy way for what you desire, not _the easy way_.

>  I.e., let me and/or anyone else who wants Plasma on X11 comaintain
> the 2
>  packages and assign any X11 issues to me/them. That would probably be the
>  least work for everyone.
>   
One of the main reasons of the Change Proposal was precisely to lower the 
maintenance. Having to filter through the tickets and assigning them to the 
relevant person is certainly more costly than not supporting X11 at all.

>  But the separate packages as I submitted them for review are the next
> best
>  solution. 
That is only your opinion, of course ;-)

[Vít Ondruch]

Dne 31. 01. 24 v 14:44 Zbigniew Jędrzejewski-Szmek napsal(a):
>  On Tue, Jan 30, 2024 at 08:45:37AM -0500, 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.
> >
> >
> >> My proposal for consideration is this:
> >> "FESCo will allow these packages in the main Fedora repositories,
> >> however they may not be included by default on any release-blocking
> >> deliverable (ISO, image, etc.)"
>  I think we should reword this proposal to address this point:
>
>  "FESCo will allow these packages in the main Fedora repositories,
>  however they may not be included by default on any release-blocking
>  deliverable (ISO, image, etc.). The KDE SIG should provide a notice
>  before major changes, but is NOT responsible for ensuring that these
>  packages adapt."
>  

Maybe it would be worth of extending the proposal with something like 
that "the -x11 package maintainers have to actively monitor relevant 
components and reassign the -x11 issues appropriately". I would not be 
surprised if that is the case already, but this could officially relief 
the KDE SIG.

Vít


>  Zbyszek
>  --
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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/[e-mail]
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
>

[Daniel P. Berrangé]

On Tue, Jan 30, 2024 at 08:38:51AM -0500, Stephen Gallagher wrote:
>  On Tue, Jan 30, 2024 at 8:07 AM Richard W.M. Jones
> <rjones(a)redhat.com&gt; wrote:
>  >
>  > On Tue, Jan 30, 2024 at 12:47:44PM +0000, Sérgio Basto wrote:
>  > > Link to the FESCo ticket: https://pagure.io/fesco/issue/3165
>  > >
>  > > and I'm very upset 
snip

>  My proposal for consideration is this:
>  "FESCo will allow these packages in the main Fedora repositories,
>  however they may not be included by default on any release-blocking
>  deliverable (ISO, image, etc.)" 
The approved KDE change https://fedoraproject.org/wiki/Changes/KDE_Plasma_6
indicates the intent for existing Plasma X11 installs to switch to Wayland
during the upgrade process.

There's no perfect answer as some users will be happy to switch to Wayland,
while others will not, while perhaps more will not even be aware of anything
changing.

IMHO if the KDE Sig wants the upgrade path to take users from X11 to
Wayland automatically, then the criteria for allowing back in RPMs
with X11 builds should include "no interference with the X11->Wayland
upgrade path determined by the KDE Sig".

The BZ ticket indicates that there was some testing to show that is not
causing a problem with the upgrades, so it might be a non-issue, but
setting clear expectations in this respect would be a good idea anyway.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

[Kevin Kofler]

Daniel P. Berrangé wrote:
>  The approved KDE change
>  https://fedoraproject.org/wiki/Changes/KDE_Plasma_6 indicates the intent
>  for existing Plasma X11 installs to switch to Wayland during the upgrade
>  process.
>  
>  There's no perfect answer as some users will be happy to switch to
>  Wayland, while others will not, while perhaps more will not even be aware
>  of anything changing.
>  
>  IMHO if the KDE Sig wants the upgrade path to take users from X11 to
>  Wayland automatically, then the criteria for allowing back in RPMs
>  with X11 builds should include "no interference with the X11->Wayland
>  upgrade path determined by the KDE Sig".
>  
>  The BZ ticket indicates that there was some testing to show that is not
>  causing a problem with the upgrades, so it might be a non-issue, but
>  setting clear expectations in this respect would be a good idea anyway. 
As I wrote (and confirmed by testing) in the BZ ticket, the packages as 
submitted already do not interfere with the X11->Wayland upgrade path 
determined by the KDE Sig, and I do not intend changing that. (Adding 
versioned self-Obsoletes could possibly theoretically achieve that, but that 
is a game I do not intend to play. The only thing I care about, which is why 
I bumped that Epoch, is that the upgrade Obsoletes is applied only ONCE on 
the upgrade to Fedora 40 and not on routine updates in Fedora 40 or on 
upgrades from Fedora 40 to later releases, because anybody who still/again 
has the -x11 packages on Fedora 40 has explicitly opted in and should not 
have to opt in repeatedly.)

While (as also stated in the BZ ticket) I disagree that it is helpful to 
forcefully remove the -x11 packages on the upgrade to F40, my packages do 
not and will not interfere with that process.

If you want to explicitly encode this in the proposal, I am OK with that, 
but then it should also explicitly say that further updates/upgrades should 
not obsolete my packages (i.e., that the KDE SIG is not allowed to bump the 
Epoch of their Obsoletes – I really do not want to get into an Epoch war 
about that Obsoletes and I hope the KDE SIG does not want that either).

        Kevin Kofler

[Michel Lind]

On Fri, Feb 02, 2024 at 12:58:27AM +0100, Kevin Kofler via devel wrote:
>  Daniel P. Berrangé wrote:
>  > The approved KDE change
>  > https://fedoraproject.org/wiki/Changes/KDE_Plasma_6 indicates the intent
>  > for existing Plasma X11 installs to switch to Wayland during the upgrade
>  > process.
>  > 
>  > There's no perfect answer as some users will be happy to switch to
>  > Wayland, while others will not, while perhaps more will not even be aware
>  > of anything changing.
>  > 
>  > IMHO if the KDE Sig wants the upgrade path to take users from X11 to
>  > Wayland automatically, then the criteria for allowing back in RPMs
>  > with X11 builds should include "no interference with the X11->Wayland
>  > upgrade path determined by the KDE Sig".
>  > 
>  > The BZ ticket indicates that there was some testing to show that is not
>  > causing a problem with the upgrades, so it might be a non-issue, but
>  > setting clear expectations in this respect would be a good idea anyway.
>  
>  As I wrote (and confirmed by testing) in the BZ ticket, the packages as 
>  submitted already do not interfere with the X11->Wayland upgrade path 
>  determined by the KDE Sig, and I do not intend changing that. (Adding 
>  versioned self-Obsoletes could possibly theoretically achieve that, but that 
>  is a game I do not intend to play. The only thing I care about, which is why 
>  I bumped that Epoch, is that the upgrade Obsoletes is applied only ONCE on 
>  the upgrade to Fedora 40 and not on routine updates in Fedora 40 or on 
>  upgrades from Fedora 40 to later releases, because anybody who still/again 
>  has the -x11 packages on Fedora 40 has explicitly opted in and should not 
>  have to opt in repeatedly.)
>  
>  While (as also stated in the BZ ticket) I disagree that it is helpful to 
>  forcefully remove the -x11 packages on the upgrade to F40, my packages do 
>  not and will not interfere with that process.
>   
There seems to be a way for both sides to get what they want here (note:
I am neither, but I hope this might be helpful)

- KDE SIG wants to obsolete X11 packages on upgrade just once
  - Apart from the impact of that, this is actually standard packaging practice
  when subpackages are no longer offered otherwise the upgrade will
  break
- If the obsolete indicates the NEVRA of the -x11 subpackage being
  obsoleted, instead of floating to the current NEVRA, you can actually
  re-provide the missing package without having to bump epoch
- KDE SIG likely also want people to test Wayland, so defaulting to the
  X11 packages being removed makes sense here
- *However* there are quite likely cases where Wayland does not work
  (yet) or could not work (without hardware replacement) for some users'
  use cases. These should not be given short shrift
- So a workaround for such cases needs to be available
- There is also concern that any issue will land on the KDE SIG's laps

This might address all concerns:
- Can we make the x11 packages be named explicitly as compat packages
  (e.g. prefixed with compat-)
- Marking them as deprecated is also reasonable. This is standard
  practice for compat packages
- KDE SIG, as part of the Change Proposal, should also document how to
  install these compat packages so affected users can install them
- After a sufficient grace period where people get their -x11 packages
  removed by default on upgrade, the compat-*-x11 packages should be
  allowed to Provide: the old non-compat name so people who upgrade
  later keep their X11 experience intact
  - This grace period should be part of the release announcement

Does this seem workable? Any feedback appreciated - I try to keep up
with this thread but I might have missed some points.

Best regards,

-- 
Michel Lind (né Salim)
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2

[Kevin Kofler]

Michel Lind wrote:
>  - KDE SIG wants to obsolete X11 packages on upgrade just once
>    - Apart from the impact of that, this is actually standard packaging
>    practice when subpackages are no longer offered otherwise the upgrade
>    will break
>  - If the obsolete indicates the NEVRA of the -x11 subpackage being
>    obsoleted, instead of floating to the current NEVRA, you can actually
>    re-provide the missing package without having to bump epoch 
That does not work if the package in F39 gets upgraded later.

That said, since F39 is going to stick to Plasma 5 and F40 is going to ship 
only Plasma 6, something like Obsoletes: kwin-x11 < 5.90 in kwin-wayland 
might work.

That said, I actually have a plan how to let users opt out of the Obsoletes 
before upgrading to F40, and that plan also depends on the Epoch: I want to 
create a Copr for F39 providing kwin-x11 5.x and plasma-workspace-x11 5.x 
packages with Epoch 1. Then the opt-in would be:
1. dnf copr enable kkofler/keep-plasma-x11-on-f40-upgrade
2. dnf upgrade
3. dnf copr disable kkofler/keep-plasma-x11-on-f40-upgrade
4. upgrade to F40 using any of the supported or unsupported methods (but DO 
NOT distro-sync F39 before upgrading – if you want to do that, do it in step 
2 with the temporary Copr enabled).

        Kevin Kofler

[Peter Boy]

I don't really want to get involved in this discussion. I don't use KDE, I
don't even use Fedora Desktop anymore. But there is one argument resp. strategy that
triggers me:

>  Am 07.02.2024 um 10:44 schrieb Michel Lind
> <salimma(a)fedoraproject.org&gt;:
>  
>  
>  - KDE SIG likely also want people to test Wayland, so defaulting to the
>   X11 packages being removed makes sense here 
If KDE Sig wants to attract users to Wayland, then the only good strategy is to make
Wayland better than the previous way (i.e. Xorg) and promote that fact actively. Then
people will be motivated to switch by themselves. Simply banning or deleting something
will only alienate people and they will switch in frustration to another alternative, i.e.
distribution in our case. This is a simple fact that can be found in all behavioral and
political sciences.

Unfortunately, some Fedora maintainers seem to take their cue from the missionaries and
conquistadors of the 16th and 17th centuries and try fire and sword and coercion. A bad
strategy in a free world.

If I remember Matthew's Fedora status report on Flock last year correctly, the
download and user numbers of Fedora Desktop are/were declining. Perhaps this is another
reason to think about appropriate strategies. 




--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
PBoy(a)fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast

[Solomon Peachy]

On Wed, Feb 07, 2024 at 01:21:15PM +0100, Peter Boy wrote:
>  Unfortunately, some Fedora maintainers seem to take their cue from
> the 
>  missionaries and conquistadors of the 16th and 17th centuries and try 
>  fire and sword and coercion. A bad strategy in a free world. 
Congratulations, you just conflated volunteer Free Software package 
maintainers with literal genocidal rapists and murders.

...That is a bad strategy in _any_ world.

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
Dowling Park, FL                      speachy (libera.chat)

[Peter Boy]

>  Am 07.02.2024 um 14:40 schrieb Solomon Peachy via devel
> <devel(a)lists.fedoraproject.org&gt;:
>  
>  you just conflated volunteer Free Software package 
>  maintainers with literal genocidal rapists and murders. 
I am not arguing about the characteristics of maintainers or people and actions, but about
the fundamental characteristics of *strategies*. Please read more carefully.

And by the way, rape and genocide was not part of the "fire and sword" strategy
to bring about a change in beliefs, values and behaviour (Christianization), but an effect
of separate, additional parallel processes (economic resource takeover) - just for
historical completion and correctness. More precisely, processes and strategies of the
adoption of economic domination instrumentalized processes and strategies of value
domination (Christianization). Your reference here to rape and genocide lacks any factual
(historical and political science) basis.

But this is way off-topic, sorry. 


On-topic is how these discussions and decisions affect Fedora distribution as a whole. And
that worries me. 



--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
PBoy(a)fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast

[Marc Deop i Argemí]

On Wednesday, 7 February 2024 13:21:15 CET Peter Boy wrote:
>  If KDE Sig wants to attract users to Wayland, then the only good
> strategy is
>  to make Wayland better than the previous way (i.e. Xorg) and promote that
>  fact actively.  
Does something make you think that we do not?

>  Simply banning or deleting something will only alienate people and
> they
>  will switch in frustration to another alternative, i.e. distribution in our
>  case. 
We are not banning nor deleting anything. We are not _supporting_ it.

>  Unfortunately, some Fedora maintainers seem to take their cue from
> the  
missionaries and conquistadors of the 16th and 17th centuries and try fire and

sword and coercion. A bad strategy in a free world.

This kind of comment is completely out of line. Please be considerate to 
others. It's a bit surprising to me that you wrote this and in the very same 
message mentioned "alienate people"

[Kevin Kofler]

Marc Deop i Argemí wrote:
>  We are not banning nor deleting anything. We are not _supporting_ it.
You (folks) deleted the subpackages and filed a FESCo ticket requesting that 
they be banned from (re)entering Fedora as separately-built packages 
maintained by others.

        Kevin Kofler

[Sérgio Basto]

On Wed, 2024-02-07 at 16:03 +0100, Marc Deop i Argemí wrote:
>  We are not banning nor deleting anything. We are not _supporting_ it.

you are removing X11 from the builds deliberately , when 
many people , members of Fedora on devel mailing list, express that
they want have X11 , in fact we have many people that defend keep X11 .

you set %bcond to 0 on kwin.spec [1] and plasma-workspace.spec [2]

on kwin.spec [3] you add 
%if ! %{with x11}
# Obsolete kwin-x11 as we are dropping the package
Obsoletes: %{name}-x11 < %{version}-%{release}
Conflicts: %{name}-x11 < %{version}-%{release}
%endif

[1]
https://src.fedoraproject.org/rpms/kwin/blob/rawhide/f/kwin.spec#_2

[2]
https://src.fedoraproject.org/rpms/plasma-workspace/blob/rawhide/f/plasma...

[3]
https://src.fedoraproject.org/rpms/kwin/blob/rawhide/f/kwin.spec#_148


you are trying discuss semantic ?

http://languagelog.ldc.upenn.edu/myl/SemanticArgument1.png



Best regards,
-- 
Sérgio M. B.

[Marc Deop i Argemí]

On Thursday, 8 February 2024 12:33:29 CET Sérgio Basto wrote:
>  you are removing X11 from the builds deliberately , 
Yes. And the moment this: https://invent.kde.org/plasma/kwin/-/issues/139 gets 
implemented we will not have to remove anything.

(remember that the Change Proposal was approved)

>  when
>  many people , members of Fedora on devel mailing list, express that
>  they want have X11 , in fact we have many people that defend keep X11 .
>  
You have said this on many occasions and no matter how many times you repeat 
it , it doesn't mean anything different.

>  you set %bcond to 0 on kwin.spec [1] and plasma-workspace.spec [2]
>   
Yes. We do. That has been explained elsewhere and , if we weren't going to 
build stuff on a copr , we wouldn't have that.

>  
>  you are trying discuss semantic ?
>   
I am saying that words have meaning. 

>  http://languagelog.ldc.upenn.edu/myl/SemanticArgument1.png 
Really?

¯\_(ツ)_/¯

[Roy Bekken]

On torsdag 8. februar 2024 19:54:58 CET Marc Deop i Argemí wrote:
>  On Thursday, 8 February 2024 12:33:29 CET Sérgio Basto wrote:
>  
>  > you are removing X11 from the builds deliberately ,
>  
>  
>  Yes. And the moment this: https://invent.kde.org/plasma/kwin/-/issues/139
>  gets  implemented we will not have to remove anything.
>  
>  (remember that the Change Proposal was approved)
>   
You mean the proposal from kde-sig that they wanted changing to plasma 6 and 
dropping X11 because they have no interest of supporting it?

Don’t see why that should prevent someone else from supporting it, especially 
after multiple people have come forward and said they relay on X11 to have an 
functional desktop.

[Marc Deop i Argemí]

On Thursday, 8 February 2024 20:21:19 CET Roy Bekken wrote:
>  You mean the proposal from kde-sig that they wanted changing to
> plasma 6 and
>  dropping X11 because they have no interest of supporting it?
>   
Yes. Interest *and* resources.

>  Don’t see why that should prevent someone else from supporting it,
>  especially after multiple people have come forward and said they relay on
>  X11 to have an functional desktop. 
The position has been explained already. We start going in circles.

[Kevin Kofler]

Marc Deop i Argemí wrote:
>  Yes. And the moment this:
> https://invent.kde.org/plasma/kwin/-/issues/139
>  gets implemented we will not have to remove anything. 
Well, then kwin-x11 will also no longer depend on kwin and your argument 
that it is a problem because it introduces a hard version lock will be moot.

        Kevin Kofler

[Marc Deop i Argemí]

On Friday, 9 February 2024 04:15:17 CET Kevin Kofler via devel wrote:
>  Well, then kwin-x11 will also no longer depend on kwin  
YESSSS

>  and your argument
>  that it is a problem because it introduces a hard version lock will be moot. 
Well, there would be no argument to be "moot" because there would be no 
problem, would it?

;-)

[Fabio Valentini]

On Thu, Feb 8, 2024 at 12:33 PM Sérgio Basto <sergio(a)serjux.com&gt; wrote:
>  On Wed, 2024-02-07 at 16:03 +0100, Marc Deop i Argemí wrote:
>  > We are not banning nor deleting anything. We are not _supporting_ it.
>
>
>  you are removing X11 from the builds deliberately , when
>  many people , members of Fedora on devel mailing list, express that
>  they want have X11 , in fact we have many people that defend keep X11 . 
One thing that seems to be overlooked in many of the posts on this thread:

Nobody can *force* the KDE Plasma maintainers to do *anything*, just
like nobody can force *any* packager to do anything. Fedora a
volunteer-run project. We're mostly doing this "for fun" (or at least,
some definition of "fun"). So if the KDE Plasma maintainers / the KDE
SIG decides that they do not want to keep supporting the Plasma / X11
session, that is their choice. However, I am not sure whether I like
it or not that there's an ongoing effort to add this functionality
back with separate packages.

For me, the only acceptable way to do this would be in a way that does
in no way make maintaining the Plasma / Wayland packages more
difficult or burdensome, since the original intent of dropping the
Plasma / X11 session was to *lower* the maintenance burden. Adding
back the Plasma / X11 session with separate packages might cause
additional overhead for the KDE SIG (for example, needing to update
kwin-x11 whenever there is a kwin update). That would be the "usual"
way to handle this according to Fedora policies.

However, that would be counter to the original purpose of dropping the
functionality from the packages maintained by the KDE SIG. But again,
nobody can *force* package maintainers to support something they don't
want to support. So in this case, I think it would be good to have
something like a clarification to the Updates Policy (and / or other
policies, as necessary) for this case to resolve the contradiction -
something like "updates for KDE Plasma packages are not required to be
coordinated with packages for the Plasma / X11 session".

I'm also unsure how handling bug reports would best work in this
situation. People *will* report bugs against the wrong components,
causing additional work for the KDE SIG. (Hell, I'm getting bug
reports filed against elementary / Pantheon packages, and there's not
even a usable Pantheon session in Fedora yet!)

Fabio

[Kevin Fenzi]

On Thu, Feb 08, 2024 at 08:43:52PM +0100, Fabio Valentini wrote:
>  
>  One thing that seems to be overlooked in many of the posts on this thread:
>  
>  Nobody can *force* the KDE Plasma maintainers to do *anything*, just
>  like nobody can force *any* packager to do anything. Fedora a
>  volunteer-run project. We're mostly doing this "for fun" (or at least,
>  some definition of "fun"). So if the KDE Plasma maintainers / the KDE
>  SIG decides that they do not want to keep supporting the Plasma / X11
>  session, that is their choice. However, I am not sure whether I like
>  it or not that there's an ongoing effort to add this functionality
>  back with separate packages.
>  
>  For me, the only acceptable way to do this would be in a way that does
>  in no way make maintaining the Plasma / Wayland packages more
>  difficult or burdensome, since the original intent of dropping the
>  Plasma / X11 session was to *lower* the maintenance burden. Adding
>  back the Plasma / X11 session with separate packages might cause
>  additional overhead for the KDE SIG (for example, needing to update
>  kwin-x11 whenever there is a kwin update). That would be the "usual"
>  way to handle this according to Fedora policies.
>  
>  However, that would be counter to the original purpose of dropping the
>  functionality from the packages maintained by the KDE SIG. But again,
>  nobody can *force* package maintainers to support something they don't
>  want to support. So in this case, I think it would be good to have
>  something like a clarification to the Updates Policy (and / or other
>  policies, as necessary) for this case to resolve the contradiction -
>  something like "updates for KDE Plasma packages are not required to be
>  coordinated with packages for the Plasma / X11 session".
>  
>  I'm also unsure how handling bug reports would best work in this
>  situation. People *will* report bugs against the wrong components,
>  causing additional work for the KDE SIG. (Hell, I'm getting bug
>  reports filed against elementary / Pantheon packages, and there's not
>  even a usable Pantheon session in Fedora yet!) 
Yeah. So, what advantages are there to this being in the main fedora
collection of packages over just in a copr?

I suppose with official packages you get bugzilla for bugs?
Although copr's get discussion threads that many people use that way.

kevin

[Sérgio Basto]

On Thu, 2024-02-08 at 20:43 +0100, Fabio Valentini wrote:
>  On Thu, Feb 8, 2024 at 12:33 PM Sérgio Basto
> <sergio(a)serjux.com&gt;
>  wrote:
>  > 
>  > On Wed, 2024-02-07 at 16:03 +0100, Marc Deop i Argemí wrote:
>  > > We are not banning nor deleting anything. We are not _supporting_
>  > > it.
>  > 
>  > 
>  > you are removing X11 from the builds deliberately , when
>  > many people , members of Fedora on devel mailing list, express that
>  > they want have X11 , in fact we have many people that defend keep
>  > X11 .
>  
>  One thing that seems to be overlooked in many of the posts on this
>  thread:
>  
>  Nobody can *force* the KDE Plasma maintainers to do *anything*, just
>  like nobody can force *any* packager to do anything.  
nobody can force me use wayland , we volunteer maintain KDE Plasma X11
, why do you think, we want force someone to do anything ? they are
force us do a new packages, they remove X11 without consensus, they can
leave the packages alone . 

>  Fedora a
>  volunteer-run project. We're mostly doing this "for fun" (or at
>  least,
>  some definition of "fun"). So if the KDE Plasma maintainers / the KDE
>  SIG decides that they do not want to keep supporting the Plasma / X11
>  session, that is their choice. However, I am not sure whether I like
>  it or not that there's an ongoing effort to add this functionality
>  back with separate packages.
>  
>  For me, the only acceptable way to do this would be in a way that
>  does
>  in no way make maintaining the Plasma / Wayland packages more
>  difficult or burdensome, since the original intent of dropping the
>  Plasma / X11 session was to *lower* the maintenance burden. 
It is a false excuse and not true, is not more difficult nor
burdensome, we had many burdensome with the default be wayland and
hundreds of bugs opened and never fixed with crashes only on wayland
session .  

>   Adding
>  back the Plasma / X11 session with separate packages might cause
>  additional overhead for the KDE SIG (for example, needing to update
>  kwin-x11 whenever there is a kwin update).  
is the opposite, KDE SIG are causing additional overhead to who want
use X11 and the package maintainer forcing use of wayland and why does
the will of KDE SIG have to prevail? 

I also maintain many KDE packages and I had a overhead with wayland
crashes 

>  That would be the "usual"
>  way to handle this according to Fedora policies.
>   
The usual is, if someone want maintain the package , they can maintain
it, no one complains about an hypothetical burden

>  However, that would be counter to the original purpose of dropping
>  the
>  functionality from the packages maintained by the KDE SIG. But again,
>  nobody can *force* package maintainers to support something they
>  don't
>  want to support.  
They don't have support X11 , they have the work of keep the removal of
X11 in their packages  .

Other thing that KDE SIG misses , is how testing , let says, as usual,
some app crash , and we ask have you wayland session or X11 session, if
you have wayland try X11 , if it runs at X11 and crash on wayland ,
this fact can help find the problem and not the opposite . 

also in kde-wayland you can run in x11 envoirment with env
QT_QPA_PLATFORM=xcb 

So just thinking removing this part of the functionalities on KDE ,
IMHO is lack of knowledge of graphics and bad for Fedora. IMHO the
future is have both technologies and not replace it 


Is very sad read that some people think in remove it and force people
use an technology that they think that don't have some important
features and issues in his opinions , is less important than false
argumentation , that will give burden . when they are burned to who
want use X11 




>  So in this case, I think it would be good to have
>  something like a clarification to the Updates Policy (and / or other
>  policies, as necessary) for this case to resolve the contradiction -
>  something like "updates for KDE Plasma packages are not required to
>  be
>  coordinated with packages for the Plasma / X11 session".
>  
>  I'm also unsure how handling bug reports would best work in this
>  situation. People *will* report bugs against the wrong components,
>  causing additional work for the KDE SIG. (Hell, I'm getting bug
>  reports filed against elementary / Pantheon packages, and there's not
>  even a usable Pantheon session in Fedora yet!)
>  
>  Fabio
>  --
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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/[e-mail]
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue 
-- 
Sérgio M. B.

[Steve Cossette]

I
On Thu, Feb 8, 2024 at 9:51 PM Sérgio Basto <sergio(a)serjux.com&gt; wrote:

>  On Thu, 2024-02-08 at 20:43 +0100, Fabio Valentini wrote:
>  > On Thu, Feb 8, 2024 at 12:33 PM Sérgio Basto <sergio(a)serjux.com&gt;
>  > wrote:
>  > >
>  > > On Wed, 2024-02-07 at 16:03 +0100, Marc Deop i Argemí wrote:
>  > > > We are not banning nor deleting anything. We are not _supporting_
>  > > > it.
>  > >
>  > >
>  > > you are removing X11 from the builds deliberately , when
>  > > many people , members of Fedora on devel mailing list, express that
>  > > they want have X11 , in fact we have many people that defend keep
>  > > X11 .
>  >
>  > One thing that seems to be overlooked in many of the posts on this
>  > thread:
>  >
>  > Nobody can *force* the KDE Plasma maintainers to do *anything*, just
>  > like nobody can force *any* packager to do anything.
>
>  nobody can force me use wayland , we volunteer maintain KDE Plasma X11
>  , why do you think, we want force someone to do anything ? they are
>  force us do a new packages, they remove X11 without consensus, they can
>  leave the packages alone .
>
>  > Fedora a
>  > volunteer-run project. We're mostly doing this "for fun" (or at
>  > least,
>  > some definition of "fun"). So if the KDE Plasma maintainers / the KDE
>  > SIG decides that they do not want to keep supporting the Plasma / X11
>  > session, that is their choice. However, I am not sure whether I like
>  > it or not that there's an ongoing effort to add this functionality
>  > back with separate packages.
>  >
>  > For me, the only acceptable way to do this would be in a way that
>  > does
>  > in no way make maintaining the Plasma / Wayland packages more
>  > difficult or burdensome, since the original intent of dropping the
>  > Plasma / X11 session was to *lower* the maintenance burden.
>
>  It is a false excuse and not true, is not more difficult nor
>  burdensome, we had many burdensome with the default be wayland and
>  hundreds of bugs opened and never fixed with crashes only on wayland
>  session .
>
>  >  Adding
>  > back the Plasma / X11 session with separate packages might cause
>  > additional overhead for the KDE SIG (for example, needing to update
>  > kwin-x11 whenever there is a kwin update).
>
>  is the opposite, KDE SIG are causing additional overhead to who want
>  use X11 and the package maintainer forcing use of wayland and why does
>  the will of KDE SIG have to prevail?
>
>  I also maintain many KDE packages and I had a overhead with wayland
>  crashes
>
>  > That would be the "usual"
>  > way to handle this according to Fedora policies.
>  >
>
>  The usual is, if someone want maintain the package , they can maintain
>  it, no one complains about an hypothetical burden
>
>  > However, that would be counter to the original purpose of dropping
>  > the
>  > functionality from the packages maintained by the KDE SIG. But again,
>  > nobody can *force* package maintainers to support something they
>  > don't
>  > want to support.
>
>  They don't have support X11 , they have the work of keep the removal of
>  X11 in their packages  .
>
>  Other thing that KDE SIG misses , is how testing , let says, as usual,
>  some app crash , and we ask have you wayland session or X11 session, if
>  you have wayland try X11 , if it runs at X11 and crash on wayland ,
>  this fact can help find the problem and not the opposite .
>
>  also in kde-wayland you can run in x11 envoirment with env
>  QT_QPA_PLATFORM=xcb
>
>  So just thinking removing this part of the functionalities on KDE ,
>  IMHO is lack of knowledge of graphics and bad for Fedora. IMHO the
>  future is have both technologies and not replace it
>
>
>  Is very sad read that some people think in remove it and force people
>  use an technology that they think that don't have some important
>  features and issues in his opinions , is less important than false
>  argumentation , that will give burden . when they are burned to who
>  want use X11
>
>
>
>
>  > So in this case, I think it would be good to have
>  > something like a clarification to the Updates Policy (and / or other
>  > policies, as necessary) for this case to resolve the contradiction -
>  > something like "updates for KDE Plasma packages are not required to
>  > be
>  > coordinated with packages for the Plasma / X11 session".
>  >
>  > I'm also unsure how handling bug reports would best work in this
>  > situation. People *will* report bugs against the wrong components,
>  > causing additional work for the KDE SIG. (Hell, I'm getting bug
>  > reports filed against elementary / Pantheon packages, and there's not
>  > even a usable Pantheon session in Fedora yet!)
>  >
>  > Fabio
>  > --
>  > _______________________________________________
>  > devel mailing list -- devel(a)lists.fedoraproject.org
>  > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  > 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/[e-mail]
>  > Do not reply to spam, report it:
>  > https://pagure.io/fedora-infrastructure/new_issue
>
>  --
>  Sérgio M. B.
>  -- 

I am not gonna reply to all of that because all we are doing at this point
is repeating the same thing. But we are NOT stopping you from using x11.
You can either build it yourself and put it on a copr (it’s not like neal
is using voodoo in his copr), use the copr we provide or …

With the change proposal, fedora (as a distro) the kde sig has proposed to
move away from packaging x11 for plasma 6, and by accepting the proposal,
fedora (as an entity) agreed.

Fedora has a reputation of moving forwards, not going backwards.


>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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/[e-mail]
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue
>

[Sérgio Basto]

On Thu, 2024-02-08 at 22:04 -0500, Steve Cossette wrote:
>  I
>  On Thu, Feb 8, 2024 at 9:51 PM Sérgio Basto <sergio(a)serjux.com&gt;
>  wrote:
>  > On Thu, 2024-02-08 at 20:43 +0100, Fabio Valentini wrote:
>  > > On Thu, Feb 8, 2024 at 12:33 PM Sérgio Basto <sergio(a)serjux.com&gt;
>  > > wrote:
>  > >
> >   
>  > > > On Wed, 2024-02-07
> at 16:03 +0100, Marc Deop i Argemí wrote:
>  > > > > We are not banning nor deleting anything. We are not
>  > > > > _supporting_
>  > > > > it.
>  > >
> >   
>  > >
> >   
>  > > > you are removing X11 from the builds
> deliberately , when
>  > > > many people , members of Fedora on devel mailing list, express
>  > > > that
>  > > > they want have X11 , in fact we have many people that defend
>  > > > keep
>  > > > X11 .
>  >
> >   
>  > > One thing that seems to be overlooked in many of
> the posts on
>  > > this
>  > > thread:
>  >
> >   
>  > > Nobody can *force* the KDE Plasma maintainers to do
> *anything*,
>  > > just
>  > > like nobody can force *any* packager to do anything. 
> >   
>  > nobody can force me use wayland , we volunteer maintain
> KDE Plasma
>  > X11
>  > , why do you think, we want force someone to do anything ? they are
>  > force us do a new packages, they remove X11 without consensus, they
>  > can
>  > leave the packages alone . 
> >   
>  > > Fedora a
>  > > volunteer-run project. We're mostly doing this "for fun" (or at
>  > > least,
>  > > some definition of "fun"). So if the KDE Plasma maintainers / the
>  > > KDE
>  > > SIG decides that they do not want to keep supporting the Plasma /
>  > > X11
>  > > session, that is their choice. However, I am not sure whether I
>  > > like
>  > > it or not that there's an ongoing effort to add this
>  > > functionality
>  > > back with separate packages.
>  >
> >   
>  > > For me, the only acceptable way to do this would be
> in a way that
>  > > does
>  > > in no way make maintaining the Plasma / Wayland packages more
>  > > difficult or burdensome, since the original intent of dropping
>  > > the
>  > > Plasma / X11 session was to *lower* the maintenance burden.
> >   
>  > It is a false excuse and not true, is not more difficult
> nor
>  > burdensome, we had many burdensome with the default be wayland and
>  > hundreds of bugs opened and never fixed with crashes only on
>  > wayland
>  > session .  
> >   
>  > >   Adding
>  > > back the Plasma / X11 session with separate packages might cause
>  > > additional overhead for the KDE SIG (for example, needing to
>  > > update
>  > > kwin-x11 whenever there is a kwin update). 
> >   
>  > is the opposite, KDE SIG are causing additional overhead
> to who
>  > want
>  > use X11 and the package maintainer forcing use of wayland and why
>  > does
>  > the will of KDE SIG have to prevail? 
> >   
>  > I also maintain many KDE packages and I had a overhead
> with wayland
>  > crashes 
> >   
>  > > That would be the "usual"
>  > > way to handle this according to Fedora policies.
>  >
> >   
> >   
>  > The usual is, if someone want
> maintain the package , they can
>  > maintain
>  > it, no one complains about an hypothetical burden
> >   
>  > > However, that would be counter to the original
> purpose of
>  > > dropping
>  > > the
>  > > functionality from the packages maintained by the KDE SIG. But
>  > > again,
>  > > nobody can *force* package maintainers to support something they
>  > > don't
>  > > want to support. 
> >   
>  > They don't have support X11 , they have the work of
> keep the
>  > removal of
>  > X11 in their packages  .
> >   
>  > Other thing that KDE SIG misses , is how testing , let
> says, as
>  > usual,
>  > some app crash , and we ask have you wayland session or X11
>  > session, if
>  > you have wayland try X11 , if it runs at X11 and crash on wayland ,
>  > this fact can help find the problem and not the opposite . 
> >   
>  > also in kde-wayland you can run in x11 envoirment with
> env
>  > QT_QPA_PLATFORM=xcb 
> >   
>  > So just thinking removing this part of the
> functionalities on KDE ,
>  > IMHO is lack of knowledge of graphics and bad for Fedora. IMHO the
>  > future is have both technologies and not replace it 
> >   
> >   
>  > Is very sad read that some
> people think in remove it and force
>  > people
>  > use an technology that they think that don't have some important
>  > features and issues in his opinions , is less important than false
>  > argumentation , that will give burden . when they are burned to who
>  > want use X11 
> >   
> >   
> >   
> >   
>  > > So in this case, I think it would be good to have
>  > > something like a clarification to the Updates Policy (and / or
>  > > other
>  > > policies, as necessary) for this case to resolve the
>  > > contradiction -
>  > > something like "updates for KDE Plasma packages are not required
>  > > to
>  > > be
>  > > coordinated with packages for the Plasma / X11 session".
>  >
> >   
>  > > I'm also unsure how handling bug reports would
> best work in this
>  > > situation. People *will* report bugs against the wrong
>  > > components,
>  > > causing additional work for the KDE SIG. (Hell, I'm getting bug
>  > > reports filed against elementary / Pantheon packages, and there's
>  > > not
>  > > even a usable Pantheon session in Fedora yet!)
>  >
> >   
>  > > Fabio
>  > > --
>  > > _______________________________________________
>  > > devel mailing list -- devel(a)lists.fedoraproject.org
>  > > To unsubscribe send an email to
>  > > devel-leave(a)lists.fedoraproject.org
>  > > 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/[e-mail]
>  > > Do not reply to spam, report it:
>  > > https://pagure.io/fedora-infrastructure/new_issue
> >   
>  > -- 
>  > Sérgio M. B.
>  > --
> >   
>  
>  
>  I am not gonna reply to all of that because all we are doing at this
>  point is repeating the same thing. But we are NOT stopping you from
>  using x11. You can either build it yourself and put it on a copr
>  (it’s not like neal is using voodoo in his copr), use the copr we
>  provide or … 
so you agree that are giving the overhead to us (the people who want
keep X11 as it is )  

>  With the change proposal, fedora (as a distro) the kde sig has
>  proposed to move away from packaging x11 for plasma 6, and by
>  accepting the proposal, fedora (as an entity) agreed.
>  
>  Fedora has a reputation of moving forwards, not going backwards. 
>  >  
Other false excuse, we not going backwards and we not moving forward,
we are moving to swamp , with people divided, which never happened to
me and I use Red Hat 1998 (more or less) and started  maintaining
packages in 2012 
>   
-- 
Sérgio M. B.

[Marc Deop i Argemí]

On Friday, 9 February 2024 11:53:01 CET Sérgio Basto wrote:
>  so you agree that are giving the overhead to us (the people who want
>  keep X11 as it is ) 
Yes!!! OF COURSE!

If you wanna maintain something you need to handle the overhead! Not the other 
way around!

[Sérgio Basto]

On Fri, 2024-02-09 at 13:21 +0100, Marc Deop i Argemí wrote:
>  On Friday, 9 February 2024 11:53:01 CET Sérgio Basto wrote:
>  > so you agree that are giving the overhead to us (the people who
>  > want
>  > keep X11 as it is )
>  
>  Yes!!! OF COURSE!
>  
>  If you wanna maintain something you need to handle the overhead! Not
>  the other 
>  way around! 
ah ok, you can give overhead to others because is not your problem, but
others can't maintain X11 because gives overhead to you. 

-- 
Sérgio M. B.

[Roy Bekken]

On fredag 9. februar 2024 04:04:04 CET Steve Cossette wrote:
>  I am not gonna reply to all of that because all we are doing at this
> point
>  is repeating the same thing. But we are NOT stopping you from using x11.
>  You can either build it yourself and put it on a copr (it’s not like neal
>  is using voodoo in his copr), use the copr we provide or …
>  
This is extremely hostile towards new people trying linux for the very 
first time, asking them to add a copr repo if they have problems with wayland 
to try X11, its unlikely they ever heard this stuff before.

Most likely they are trying out Fedora on a live media.

>  With the change proposal, fedora (as a distro) the kde sig has
> proposed to
>  move away from packaging x11 for plasma 6, and by accepting the proposal,
>  fedora (as an entity) agreed.
>  
>  Fedora has a reputation of moving forwards, not going backwards.
>   
Moving so fast forward that they are leaving the users behind.

If Fedora is so great then why do I find stuff like this?
https://github.com/Zer0CoolX/Fedora-KDE-Minimal-Install-Guide

15 Forks and 167 Stars btw

[Neal Gompa]

On Fri, Feb 9, 2024 at 11:06 AM Roy Bekken <roy.bekken(a)gmail.com&gt; wrote:
>  On fredag 9. februar 2024 04:04:04 CET Steve Cossette wrote:
>  > I am not gonna reply to all of that because all we are doing at this point
>  > is repeating the same thing. But we are NOT stopping you from using x11.
>  > You can either build it yourself and put it on a copr (it’s not like neal
>  > is using voodoo in his copr), use the copr we provide or …
>  >
>  This is extremely hostile towards new people trying linux for the very
>  first time, asking them to add a copr repo if they have problems with wayland
>  to try X11, its unlikely they ever heard this stuff before.
>
>  Most likely they are trying out Fedora on a live media.
>  
And they're not going to get an X11 experience on live media even now.
Wayland has been used for all environment modes since Fedora 36.

>  > With the change proposal, fedora (as a distro) the kde sig has
> proposed to
>  > move away from packaging x11 for plasma 6, and by accepting the proposal,
>  > fedora (as an entity) agreed.
>  >
>  > Fedora has a reputation of moving forwards, not going backwards.
>  >
>  Moving so fast forward that they are leaving the users behind.
>
>  If Fedora is so great then why do I find stuff like this?
>  https://github.com/Zer0CoolX/Fedora-KDE-Minimal-Install-Guide
>
>  15 Forks and 167 Stars btw
>  
That is not a particularly good indication of popularity. Also, it's 4
years out of date.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Roy Bekken]

On fredag 9. februar 2024 17:41:33 CET Neal Gompa wrote:
>  On Fri, Feb 9, 2024 at 11:06 AM Roy Bekken
> <roy.bekken(a)gmail.com&gt; wrote:
>  
>  >
>  >
>  > On fredag 9. februar 2024 04:04:04 CET Steve Cossette wrote:
>  > 
>  > > I am not gonna reply to all of that because all we are doing at this
>  > > point
>  > > is repeating the same thing. But we are NOT stopping you from using
>  > > x11.
>  > > You can either build it yourself and put it on a copr (it’s not like
>  > > neal
>  > > is using voodoo in his copr), use the copr we provide or …
>  > >
>  > >
>  > 
>  > This is extremely hostile towards new people trying linux for the very
>  > first time, asking them to add a copr repo if they have problems with
>  > wayland  to try X11, its unlikely they ever heard this stuff before.
>  >
>  >
>  >
>  > Most likely they are trying out Fedora on a live media.
>  >
>  >
>  
>  
>  And they're not going to get an X11 experience on live media even now.
>  Wayland has been used for all environment modes since Fedora 36. 
I am aware if
this. So you are saying that its perfectly fine that someone new 
to linux boot into a desktop that microstutters when they move windows around?
>  
>  
>  > > With the change proposal, fedora (as a distro) the kde sig has proposed
>  > > to
>  > > move away from packaging x11 for plasma 6, and by accepting the
>  > > proposal,
>  > > fedora (as an entity) agreed.
>  > >
>  > >
>  > >
>  > > Fedora has a reputation of moving forwards, not going backwards.
>  > >
>  > >
>  > 
>  > Moving so fast forward that they are leaving the users behind.
>  >
>  >
>  >
>  > If Fedora is so great then why do I find stuff like this?
>  > https://github.com/Zer0CoolX/Fedora-KDE-Minimal-Install-Guide
>  >
>  >
>  >
>  > 15 Forks and 167 Stars btw
>  >
>  >
>  
>  
>  That is not a particularly good indication of popularity. Also, it's 4
>  years out of date. 
Just like the majority of Fedora users don’t read the devel
mailing lists, the 
majority don’t give stars when they download from gh.

Yeah its 4 years old, I don’t know what happens but im gonna take a wild guess 
and assume that person gave up.

[Neal Gompa]

On Fri, Feb 9, 2024 at 12:16 PM Roy Bekken <roy.bekken(a)gmail.com&gt; wrote:
>  On fredag 9. februar 2024 17:41:33 CET Neal Gompa wrote:
>  > On Fri, Feb 9, 2024 at 11:06 AM Roy Bekken <roy.bekken(a)gmail.com&gt; wrote:
>  >
>  > >
>  > >
>  > > On fredag 9. februar 2024 04:04:04 CET Steve Cossette wrote:
>  > >
>  > > > I am not gonna reply to all of that because all we are doing at this
>  > > > point
>  > > > is repeating the same thing. But we are NOT stopping you from using
>  > > > x11.
>  > > > You can either build it yourself and put it on a copr (it’s not like
>  > > > neal
>  > > > is using voodoo in his copr), use the copr we provide or …
>  > > >
>  > > >
>  > >
>  > > This is extremely hostile towards new people trying linux for the very
>  > > first time, asking them to add a copr repo if they have problems with
>  > > wayland  to try X11, its unlikely they ever heard this stuff before.
>  > >
>  > >
>  > >
>  > > Most likely they are trying out Fedora on a live media.
>  > >
>  > >
>  >
>  >
>  > And they're not going to get an X11 experience on live media even now.
>  > Wayland has been used for all environment modes since Fedora 36.
>  I am aware if this. So you are saying that its perfectly fine that someone new
>  to linux boot into a desktop that microstutters when they move windows around? 
No, it's not fine. Just like it's not fine to get random
tear/corruption snow when moving things around or opening windows on
X11.

The difference is that we can actually do something about those issues
with Plasma Wayland when people report them. *Tons* of these kinds of
issues were fixed over the past 3 years, and Plasma 6 brings a huge
upgrade around this stuff too. And the whole graphics pipeline is
fully under the control of KDE Plasma, so we can do things we've never
done before. That's why we can do VRR, HDR, VR, mixed-DPI, fractional
scaling, and so much more.

We can do things that even other Wayland desktops can't do because our
architecture is flexible enough to do it. With Plasma X11, our necks
are hanging to the dying albatross that is the X server and our hands
are tied behind our backs when we want to actually do something to
improve the experience. These are not issues with Plasma Wayland.

Because Plasma Wayland... is just KDE Plasma.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Roy Bekken]

On fredag 9. februar 2024 18:28:15 CET Neal Gompa wrote:
>  The difference is that we can actually do something about those
> issues
>  with Plasma Wayland when people report them. *Tons* of these kinds of
>  issues were fixed over the past 3 years, and Plasma 6 brings a huge
>  upgrade around this stuff too. And the whole graphics pipeline is
>  fully under the control of KDE Plasma, so we can do things we've never
>  done before. That's why we can do VRR, HDR, VR, mixed-DPI, fractional
>  scaling, and so much more.
>   
Nobody is saying that this is not awesome stuff but as of today, on some 
hardware, Wayland is not a great experience.

I just booted Fedora-KDE-Live-x86_64-Rawhide-20240207.n.0.iso
First impression is great but I’ll start moving(fast) the welcome center 
window around and the desktop randomly freezes from 30sec to 90ses.

This is on a 1080 with nouveau, im not sure if its better with the proprietary 
drivers.

[Neal Gompa]

On Fri, Feb 9, 2024 at 2:25 PM Roy Bekken <roy.bekken(a)gmail.com&gt; wrote:
>  On fredag 9. februar 2024 18:28:15 CET Neal Gompa wrote:
>  > The difference is that we can actually do something about those issues
>  > with Plasma Wayland when people report them. *Tons* of these kinds of
>  > issues were fixed over the past 3 years, and Plasma 6 brings a huge
>  > upgrade around this stuff too. And the whole graphics pipeline is
>  > fully under the control of KDE Plasma, so we can do things we've never
>  > done before. That's why we can do VRR, HDR, VR, mixed-DPI, fractional
>  > scaling, and so much more.
>  >
>  Nobody is saying that this is not awesome stuff but as of today, on some
>  hardware, Wayland is not a great experience.
>
>  I just booted Fedora-KDE-Live-x86_64-Rawhide-20240207.n.0.iso
>  First impression is great but I’ll start moving(fast) the welcome center
>  window around and the desktop randomly freezes from 30sec to 90ses.
>
>  This is on a 1080 with nouveau, im not sure if its better with the proprietary
>  drivers.
>  
It will definitely be better with the proprietary drivers. One of the
members of Fedora KDE has the same graphics card and daily drives
Plasma Wayland with the proprietary drivers.

GTX 16, RTX 20, RTX 30, and RTX 40 series GPUs will hopefully work
much better out of the box starting with tonight's compose since we
will have the new nouveau driver stack fully enabled for those cards.
Sadly, that doesn't help folks with older GPUs (like my GTX 960 or
your GTX 1080), but it'll still be an improvement overall.


-- 
真実はいつも一つ！/ Always, there's only one truth!

[Marcin Juszkiewicz]

W dniu 9.02.2024 o 20:25, Roy Bekken pisze:
>  I just booted Fedora-KDE-Live-x86_64-Rawhide-20240207.n.0.iso First
>  impression is great but I’ll start moving(fast) the welcome center 
>  window around and the desktop randomly freezes from 30sec to 90ses.
>  
>  This is on a 1080 with nouveau, im not sure if its better with the
>  proprietary drivers. 
NVidia 10xx is the worst option for nouveau.

It is too new to have reclocking support (NVidia never released 
blobs/code for it for this generation).

And it is too old to use new GSP based approach where you run tens of 
megabytes of blob and use nouveau on top of it.

For 1080 the only option is proprietary driver. With all problems it 
generates.


I had 1050 Ti. Sold it, moved to Radeon 6700 XT. Wayland works, X11 
works, Cyberpunk 2077 works (both under Linux and Windows).

[Kevin Kofler]

Neal Gompa wrote:
>  Because Plasma Wayland... is just KDE Plasma. 
But in the real world, users use applications that are not KDE or even Qt 
applications (or ones that use old versions of Qt that will never natively 
support Wayland, or old versions of other toolkits in the same situation, 
such as GTK 2, for that matter). Even if they use the most recent version 
of, say, GTK, there will always be differences in interpretation of the 
Wayland specifications which lead to interoperability problems (e.g., both 
GTK and GNOME Shell deliberately refusing to support server-side window 
decorations on Wayland, but also genuine interoperability bugs that can take 
a long time to get fixed such as this touch input bug: 
https://bugs.kde.org/show_bug.cgi?id=452967 that was finally fixed 1½ years 
after having been initially filed and sent back and forth between KDE and 
GTK bug trackers). So in the real world, there ARE interoperability problems 
that you just cannot argue away. What real users (will) use is NOT "just KDE 
Plasma".

        Kevin Kofler

[Kilian Hanich]

Am 09.02.24 um 18:28 schrieb Neal Gompa:
>  On Fri, Feb 9, 2024 at 12:16 PM Roy Bekken
> <roy.bekken(a)gmail.com&gt; wrote:
> >
> > On fredag 9. februar 2024 17:41:33 CET Neal Gompa wrote:
> >> On Fri, Feb 9, 2024 at 11:06 AM Roy Bekken <roy.bekken(a)gmail.com&gt; wrote:
> >>
> >>>
> >>>
> >>> On fredag 9. februar 2024 04:04:04 CET Steve Cossette wrote:
> >>>
> >>>> I am not gonna reply to all of that because all we are doing at this
> >>>> point
> >>>> is repeating the same thing. But we are NOT stopping you from using
> >>>> x11.
> >>>> You can either build it yourself and put it on a copr (it’s not like
> >>>> neal
> >>>> is using voodoo in his copr), use the copr we provide or …
> >>>>
> >>>>
> >>>
> >>> This is extremely hostile towards new people trying linux for the very
> >>> first time, asking them to add a copr repo if they have problems with
> >>> wayland  to try X11, its unlikely they ever heard this stuff before.
> >>>
> >>>
> >>>
> >>> Most likely they are trying out Fedora on a live media.
> >>>
> >>>
> >>
> >>
> >> And they're not going to get an X11 experience on live media even now.
> >> Wayland has been used for all environment modes since Fedora 36.
> > I am aware if this. So you are saying that its perfectly fine that someone new
> > to linux boot into a desktop that microstutters when they move windows around?
>
>  No, it's not fine. Just like it's not fine to get random
>  tear/corruption snow when moving things around or opening windows on
>  X11.
>
>  The difference is that we can actually do something about those issues
>  with Plasma Wayland when people report them. *Tons* of these kinds of
>  issues were fixed over the past 3 years, and Plasma 6 brings a huge
>  upgrade around this stuff too. And the whole graphics pipeline is
>  fully under the control of KDE Plasma, so we can do things we've never
>  done before. That's why we can do VRR, HDR, VR, mixed-DPI, fractional
>  scaling, and so much more.
>
>  We can do things that even other Wayland desktops can't do because our
>  architecture is flexible enough to do it. With Plasma X11, our necks
>  are hanging to the dying albatross that is the X server and our hands
>  are tied behind our backs when we want to actually do something to
>  improve the experience. These are not issues with Plasma Wayland.
>
>  Because Plasma Wayland... is just KDE Plasma.
>
>
>  
Quite a bit of topic from my part, but is your pipeline for Wayland
flexible enough to turn off any kind of display sync (even in windowed
mode) if the user wants that?

Sure, it has its downside (e.g. tearing can happen), but I rather have
that than the added latency (even if very minimal) of such a sync (and
yes, that includes VRR which has a considerable smaller one than normal
V-SYNC).

[Neal Gompa]

On Fri, Feb 9, 2024 at 9:10 PM Kilian Hanich via devel
<devel(a)lists.fedoraproject.org&gt; wrote:
>  Am 09.02.24 um 18:28 schrieb Neal Gompa:
>  > On Fri, Feb 9, 2024 at 12:16 PM Roy Bekken <roy.bekken(a)gmail.com&gt; wrote:
>  >>
>  >> On fredag 9. februar 2024 17:41:33 CET Neal Gompa wrote:
>  >>> On Fri, Feb 9, 2024 at 11:06 AM Roy Bekken <roy.bekken(a)gmail.com&gt;
> wrote:
>  >>>
>  >>>>
>  >>>>
>  >>>> On fredag 9. februar 2024 04:04:04 CET Steve Cossette wrote:
>  >>>>
>  >>>>> I am not gonna reply to all of that because all we are doing at
> this
>  >>>>> point
>  >>>>> is repeating the same thing. But we are NOT stopping you from using
>  >>>>> x11.
>  >>>>> You can either build it yourself and put it on a copr (it’s not
> like
>  >>>>> neal
>  >>>>> is using voodoo in his copr), use the copr we provide or …
>  >>>>>
>  >>>>>
>  >>>>
>  >>>> This is extremely hostile towards new people trying linux for the very
>  >>>> first time, asking them to add a copr repo if they have problems with
>  >>>> wayland  to try X11, its unlikely they ever heard this stuff before.
>  >>>>
>  >>>>
>  >>>>
>  >>>> Most likely they are trying out Fedora on a live media.
>  >>>>
>  >>>>
>  >>>
>  >>>
>  >>> And they're not going to get an X11 experience on live media even now.
>  >>> Wayland has been used for all environment modes since Fedora 36.
>  >> I am aware if this. So you are saying that its perfectly fine that someone new
>  >> to linux boot into a desktop that microstutters when they move windows around?
>  >
>  > No, it's not fine. Just like it's not fine to get random
>  > tear/corruption snow when moving things around or opening windows on
>  > X11.
>  >
>  > The difference is that we can actually do something about those issues
>  > with Plasma Wayland when people report them. *Tons* of these kinds of
>  > issues were fixed over the past 3 years, and Plasma 6 brings a huge
>  > upgrade around this stuff too. And the whole graphics pipeline is
>  > fully under the control of KDE Plasma, so we can do things we've never
>  > done before. That's why we can do VRR, HDR, VR, mixed-DPI, fractional
>  > scaling, and so much more.
>  >
>  > We can do things that even other Wayland desktops can't do because our
>  > architecture is flexible enough to do it. With Plasma X11, our necks
>  > are hanging to the dying albatross that is the X server and our hands
>  > are tied behind our backs when we want to actually do something to
>  > improve the experience. These are not issues with Plasma Wayland.
>  >
>  > Because Plasma Wayland... is just KDE Plasma.
>  >
>  >
>  >
>
>  Quite a bit of topic from my part, but is your pipeline for Wayland
>  flexible enough to turn off any kind of display sync (even in windowed
>  mode) if the user wants that?
>
>  Sure, it has its downside (e.g. tearing can happen), but I rather have
>  that than the added latency (even if very minimal) of such a sync (and
>  yes, that includes VRR which has a considerable smaller one than normal
>  V-SYNC). 
Technically, turning off display sync completely is quite difficult
right now since the actual driver stack in Linux underneath everything
(both Wayland and X11) uses implicit sync right now (Linux kernel
drivers, Mesa drivers, etc.).

That said, there's a move to support explicit sync in Wayland[1], and
the first steps of that for KWin have been written up as a merge
request[2]. Once there's an agreed upon mechanism for explicit sync,
it would be possible to support something like that.

[1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/90
[2]: https://invent.kde.org/plasma/kwin/-/merge_requests/4800




--
真実はいつも一つ！/ Always, there's only one truth!

[Kilian Hanich]

Am 10.02.24 um 09:47 schrieb Neal Gompa:
>  Technically, turning off display sync completely is quite difficult
>  right now since the actual driver stack in Linux underneath everything
>  (both Wayland and X11) uses implicit sync right now (Linux kernel
>  drivers, Mesa drivers, etc.).
>  
Interesting considering that I once read (but haven't fact check) that
the Vulkan spec explicitly requires explicit sync instead of implicit,
even if you for parts of it.

>  That said, there's a move to support explicit sync in Wayland[1],
> and
>  the first steps of that for KWin have been written up as a merge
>  request[2]. Once there's an agreed upon mechanism for explicit sync,
>  it would be possible to support something like that.
>
>  [1]:https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_reque...
>  [2]:https://invent.kde.org/plasma/kwin/-/merge_requests/4800 
Interesting read. I will just hope that this won't be something which
ends up in "noone actually still looks at it"-land as some things
sometimes end up in because people focused on different things and then
forgot about it (well, kind natural for volunteer projects I guess).


Kilian Hanich

[Neal Gompa]

On Sun, Feb 11, 2024 at 1:50 AM Kilian Hanich <khanich.opensource(a)gmx.de&gt; wrote:
>  Am 10.02.24 um 09:47 schrieb Neal Gompa:
>  > Technically, turning off display sync completely is quite difficult
>  > right now since the actual driver stack in Linux underneath everything
>  > (both Wayland and X11) uses implicit sync right now (Linux kernel
>  > drivers, Mesa drivers, etc.).
>  >
>
>  Interesting considering that I once read (but haven't fact check) that
>  the Vulkan spec explicitly requires explicit sync instead of implicit,
>  even if you for parts of it.
>  
I don't know enough about Vulkan to confidently say one way or
another. Especially since I'm pretty sure parts of it are one and the
other.

>  > That said, there's a move to support explicit sync in
> Wayland[1], and
>  > the first steps of that for KWin have been written up as a merge
>  > request[2]. Once there's an agreed upon mechanism for explicit sync,
>  > it would be possible to support something like that.
>  >
>  > [1]:https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_reque...
>  > [2]:https://invent.kde.org/plasma/kwin/-/merge_requests/4800
>
>  Interesting read. I will just hope that this won't be something which
>  ends up in "noone actually still looks at it"-land as some things
>  sometimes end up in because people focused on different things and then
>  forgot about it (well, kind natural for volunteer projects I guess).
>  
That's not going to happen because Direct3D 12 requires explicit sync.
That's been driving the change to support it in the Linux graphics
stack in the first place.


-- 
真実はいつも一つ！/ Always, there's only one truth!

[Kevin Kofler]

Neal Gompa wrote:

>  On Fri, Feb 9, 2024 at 11:06 AM Roy Bekken wrote:
> > If Fedora is so great then why do I find stuff like this?
> > https://github.com/Zer0CoolX/Fedora-KDE-Minimal-Install-Guide
> >
> > 15 Forks and 167 Stars btw
>  
>  That is not a particularly good indication of popularity. Also, it's 4
>  years out of date. 
That is what happens when users have to rely on such self-help HOWTOs to 
work around distribution deficiencies. Those HOWTOs invariably tend to grow 
out of date.

By the way, what that link does not mention when it talks about "multiple 
packages for the same thing" is browsers / web engines. The Spin ships 
several applications using QtWebEngine, e.g., KMail, so that engine is not 
going away. But in addition to one or two browsers using that, which add 
little to no overhead size-wise, it still ships the duplicate application 
Firefox that bundles its own, completely different web engine. See: 
https://bugzilla.redhat.com/show_bug.cgi?id=1920298 . (The main argument has 
always been market share, which at 2% market share and steadily decreasing 
does not sound relevant anymore.)

        Kevin Kofler

[Marc Deop i Argemí]

On Saturday, 10 February 2024 01:11:03 CET Kevin Kofler via devel wrote:
>  By the way, what that link does not mention when it talks about
> "multiple
>  packages for the same thing" is browsers / web engines. The Spin ships
>  several applications using QtWebEngine, e.g., KMail, so that engine is not
>  going away. But in addition to one or two browsers using that, which add
>  little to no overhead size-wise, it still ships the duplicate application
>  Firefox that bundles its own, completely different web engine. See:
>  https://bugzilla.redhat.com/show_bug.cgi?id=1920298 . (The main argument has
>  always been market share, which at 2% market share and steadily decreasing
>  does not sound relevant anymore.) 
Let's stay on topic.

Thanks.

[Kevin Kofler]

Fabio Valentini wrote:
>  Nobody can *force* the KDE Plasma maintainers to do *anything*, just
>  like nobody can force *any* packager to do anything. 
That is exactly why nobody should be allowed to force plasma-workspace-x11 
and kwin-x11 out of the Fedora repository.

We are not forcing the KDE Plasma maintainers to do anything, we just want 
to maintain 2 packages that conform to all Fedora guidelines in Fedora.

        Kevin Kofler

[Steve Cossette]

On 2024-02-07 7:21 a.m., Peter Boy wrote:
>  I don't really want to get involved in this discussion. I
> don't use KDE, I don't even use Fedora Desktop anymore. But there is one argument
> resp. strategy that triggers me:
>
> > Am 07.02.2024 um 10:44 schrieb Michel Lind <salimma(a)fedoraproject.org&gt;:
> >
> >
> > - KDE SIG likely also want people to test Wayland, so defaulting to the
> >   X11 packages being removed makes sense here
>  If KDE Sig wants to attract users to Wayland, then the only good strategy is to make
> Wayland better than the previous way (i.e. Xorg) and promote that fact actively. Then
> people will be motivated to switch by themselves. Simply banning or deleting something
> will only alienate people and they will switch in frustration to another alternative, i.e.
> distribution in our case. This is a simple fact that can be found in all behavioral and
> political sciences.
>
>  Unfortunately, some Fedora maintainers seem to take their cue from the missionaries and
> conquistadors of the 16th and 17th centuries and try fire and sword and coercion. A bad
> strategy in a free world.
>
>  If I remember Matthew's Fedora status report on Flock last year correctly, the
> download and user numbers of Fedora Desktop are/were declining. Perhaps this is another
> reason to think about appropriate strategies.
>
>
>
>
>  --
>  Peter Boy
>  https://fedoraproject.org/wiki/User:Pboy
>  PBoy(a)fedoraproject.org
>
>  Timezone: CET (UTC+1) / CEST (UTC+2)
>
>  Fedora Server Edition Working Group member
>  Fedora Docs team contributor and board member
>  Java developer and enthusiast
>
>
>
>  --
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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/[e-mail]
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Better how though? That is highly subjective... for some people (Like 
me), it's good right now!

[Richard W.M. Jones]

On Tue, Jan 30, 2024 at 08:38:51AM -0500, Stephen Gallagher wrote:
>  3) Fedora has a long-standing and well-communicated stance that we
> are
>  a Wayland distribution first and foremost and that X11 support is
>  intended as a migration-support tool rather than a first-class
>  citizen. 
Does it?  This is very much news to me, so I don't think you can call
it "well-communicated".  We also have an XFCE desktop spin and
probably others that require X11.
https://fedoraproject.org/uk/spins/xfce/

In addition Wayland doesn't actually replace all the basic
functionality of X11 even after all these years, which is why I need
to use it.

>  4) There was a comment on the FESCo ticket to the effect of
> '"you must
>  move to Wayland because no one maintains X11!". Here are some people
>  who are maintaining X11 packages, so let them do their thing.' This is
>  misleading, as the move to Wayland is specifically because the
>  upstream of X11 *itself* is largely unmaintained. These packages are
>  not maintaining X11, they are adding new dependencies on it. 
They're maintaining parts of the X11 stack.

>  My proposal for consideration is this:
>  "FESCo will allow these packages in the main Fedora repositories,
>  however they may not be included by default on any release-blocking
>  deliverable (ISO, image, etc.)" 
It seems quite strong.  I'm unclear why having X11 packages and spins
for those that want to use them is a problem.  It seems like the
missing functionality of Wayland is the bigger issue that needs to be
addressed.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

[Steven A. Falco]

On 1/30/24 08:55 AM, Richard W.M. Jones wrote:
>  On Tue, Jan 30, 2024 at 08:38:51AM -0500, Stephen Gallagher wrote:
> > 3) Fedora has a long-standing and well-communicated stance that we are
> > a Wayland distribution first and foremost and that X11 support is
> > intended as a migration-support tool rather than a first-class
> > citizen.
>  
>  Does it?  This is very much news to me, so I don't think you can call
>  it "well-communicated".  We also have an XFCE desktop spin and
>  probably others that require X11.
>  https://fedoraproject.org/uk/spins/xfce/
>  
>  In addition Wayland doesn't actually replace all the basic
>  functionality of X11 even after all these years, which is why I need
>  to use it. 
I'm in the same boat.  Back in September when this topic came up, folks were invited
to write bugs so the missing functionality could presumably be worked on.

I wrote two bugs:

Bug 2239016 - Plasma(Wayland) does not honor window positioning when setting window
geometry
Bug 2239029 - Plasma(Wayland) does not save windows between sessions

For 2239016 the response was "That's just how wayland works" and for 2239029
someone added a reference to an upstream KDE bug (from 2021).

I realize that this is a volunteer-driven project, and that I cannot expect someone to
address the above wayland limitations, especially since the wayland design philosophy
appears to exclude such features.

But that doesn't change the fact that I need the missing functionality, and based on
how this discussion is going, I personally doubt wayland will ever meet my needs.

I'm delighted that there are like-minded folks who want to maintain X11.  Please allow
them to do so.

	Steve

> > 4) There was a comment on the FESCo ticket to the effect of
> '"you must
> > move to Wayland because no one maintains X11!". Here are some people
> > who are maintaining X11 packages, so let them do their thing.' This is
> > misleading, as the move to Wayland is specifically because the
> > upstream of X11 *itself* is largely unmaintained. These packages are
> > not maintaining X11, they are adding new dependencies on it.
>  
>  They're maintaining parts of the X11 stack.
>  
> > My proposal for consideration is this:
> > "FESCo will allow these packages in the main Fedora repositories,
> > however they may not be included by default on any release-blocking
> > deliverable (ISO, image, etc.)"
>  
>  It seems quite strong.  I'm unclear why having X11 packages and spins
>  for those that want to use them is a problem.  It seems like the
>  missing functionality of Wayland is the bigger issue that needs to be
>  addressed.
>  
>  Rich.
>

[Marc Deop i Argemí]

On Tuesday, 30 January 2024 15:57:12 CET Steven A. Falco wrote:
>  I'm delighted that there are like-minded folks who want to
> maintain X11. 
>  Please allow them to do so. 
I will just quote you what Stephen said:

>  This is
>  misleading, as the move to Wayland is specifically because the
>  upstream of X11 *itself* is largely unmaintained. These packages are
>  not maintaining X11, they are adding new dependencies on it.

[Sérgio Basto]

On Tue, 2024-01-30 at 09:57 -0500, Steven A. Falco wrote:
>  On 1/30/24 08:55 AM, Richard W.M. Jones wrote:
>  > On Tue, Jan 30, 2024 at 08:38:51AM -0500, Stephen Gallagher wrote:
>  > > 3) Fedora has a long-standing and well-communicated stance that
>  > > we are
>  > > a Wayland distribution first and foremost and that X11 support is
>  > > intended as a migration-support tool rather than a first-class
>  > > citizen.
>  > 
>  > Does it?  This is very much news to me, so I don't think you can
>  > call
>  > it "well-communicated".  We also have an XFCE desktop spin and
>  > probably others that require X11.
>  > https://fedoraproject.org/uk/spins/xfce/
>  > 
>  > In addition Wayland doesn't actually replace all the basic
>  > functionality of X11 even after all these years, which is why I
>  > need
>  > to use it.
>  
>  I'm in the same boat.  Back in September when this topic came up,
>  folks were invited to write bugs so the missing functionality could
>  presumably be worked on.
>  
>  I wrote two bugs:
>  
>  Bug 2239016 - Plasma(Wayland) does not honor window positioning when
>  setting window geometry
>  Bug 2239029 - Plasma(Wayland) does not save windows between sessions
>  
>  For 2239016 the response was "That's just how wayland works" and for
>  2239029 someone added a reference to an upstream KDE bug (from 2021).
>  
>  I realize that this is a volunteer-driven project, and that I cannot
>  expect someone to address the above wayland limitations, especially
>  since the wayland design philosophy appears to exclude such features.
>  
>  But that doesn't change the fact that I need the missing
>  functionality, and based on how this discussion is going, I
>  personally doubt wayland will ever meet my needs.
>  
>  I'm delighted that there are like-minded folks who want to maintain
>  X11.  Please allow them to do so.
>  
>          Steve 

Steven, thank you for the serene explanations and for highlighting an
important point about waynland, wayland seems to miss some important
features. 



>  > > 4) There was a comment on the FESCo ticket to the effect of
> '"you
>  > > must
>  > > move to Wayland because no one maintains X11!". Here are some
>  > > people
>  > > who are maintaining X11 packages, so let them do their thing.'
>  > > This is
>  > > misleading, as the move to Wayland is specifically because the
>  > > upstream of X11 *itself* is largely unmaintained. These packages
>  > > are
>  > > not maintaining X11, they are adding new dependencies on it.
>  > 
>  > They're maintaining parts of the X11 stack.
>  > 
>  > > My proposal for consideration is this:
>  > > "FESCo will allow these packages in the main Fedora repositories,
>  > > however they may not be included by default on any release-
>  > > blocking
>  > > deliverable (ISO, image, etc.)"
>  > 
>  > It seems quite strong.  I'm unclear why having X11 packages and
>  > spins
>  > for those that want to use them is a problem.  It seems like the
>  > missing functionality of Wayland is the bigger issue that needs to
>  > be
>  > addressed.
>  > 
>  > Rich.
>  > 
>  --
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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/[e-mail]
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue 

-- 
Sérgio M. B.

[Kevin Kofler]

Steven A. Falco wrote:
>  Bug 2239016 - Plasma(Wayland) does not honor window positioning when
>  setting window geometry
>  For 2239016 the response was "That's just how wayland works" 
As far as I know, there are actually some discussions about this issue in 
the upstream Wayland community, but there is a lot of divergence of opinions 
between compositor developers whether this should be allowed at all (GNOME 
in particular is against this and several other advanced features that users 
know from X11 and want) and if yes, how exactly the API should look like. 
See, e.g.:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests...
for one proposed protocol implementation.

Of course, having a protocol would not instantly make this work for you. The 
protocol will have to be implemented both by kwin-wayland and by the toolkit 
your application uses. Which also means that the application will have to be 
ported to the latest major version of the toolkit (e.g., Qt 6), because this 
is a new feature and as such will likely never be backported to legacy 
toolkit versions (such as Qt 5). Though at least for Konsole, that last part 
should not be an issue.

>  Bug 2239029 - Plasma(Wayland) does not save windows between sessions
That one is also reportedly being worked on, but it is a particularly big 
mess (i.e., probably requires more than one new Wayland protocol to solve 
completely), so I do not expect this to be solved completely any time soon. 
(The fact that the upstream bug was opened back in 2021 indeed gives you an 
idea.) As I understand it, Plasma 6.0 will have no support at all for this, 
Plasma 6.1 will remember the applications, but neither will KWin (or the 
applications themselves, but then see also your other issue) remember their 
window geometry nor will the applications remember their state. As far as I 
know, there is at this time no Wayland protocol to tell applications to save 
their state. A more complete session save/restore implementation is expected 
by upstream KDE developers only for around 2025.


There are also more X11 features of this type that are not currently 
implemented in Wayland.

        Kevin Kofler

[Garry T. Williams]

On Tuesday, 30 January 2024 08:07:25 EST Richard W.M. Jones wrote:
>  On Tue, Jan 30, 2024 at 12:47:44PM +0000, Sérgio Basto wrote:
>  > Link to the FESCo ticket: https://pagure.io/fesco/issue/3165
>  > 
>  > and I'm very upset 
>  
>  Assume best intent first of all. 
I quit trying to use Wayland a long time ago because of the various
bugs.  When I saw this thread, I decided I better get ready and logged
out/in Plasma Wayland.

OK, I can live with windows that don't remember their geometry from
last session.  And I don't really have to have that last session
remembered and restored.  But...

I went to compose an E-mail message using kmail and its composer
window and noticed it was broken.[*]  I couldn't even find a bug
report about this.  I fear it's because many others just ignored the
various bugs and went back to using X11.

I hope my report can be resolved before I am forced to use Wayland.  I
understand that I am late to the party because I just ignored this for
so long.


_____________________
[*] https://bugs.kde.org/show_bug.cgi?id=480984

-- 
Garry T. Williams

[Kevin Kofler]

Garry T. Williams wrote:
>  I hope my report can be resolved before I am forced to use Wayland.
You will not be forced to use Wayland. Stay tuned.

        Kevin Kofler

[Garry T. Williams]

On Wednesday, February 7, 2024 4:06:46 AM EDT Kevin Kofler via devel wrote:
>  Garry T. Williams wrote:
>  > I hope my report can be resolved before I am forced to use Wayland.
>  
>  You will not be forced to use Wayland. Stay tuned. 
In an effort to test a Wayland bug I reported upstream, I upgraded my
laptop to f40.  (I am holding off on upgrading my workstation.)  My
reported bug is still there, but here I am without x11.  I installed
kwin-x11.  My login screen no longer offers to run it instead of
kwin-wayland.   Is there a way to run x11 on f40?  (There are still
several annoying bugs in Wayland that I would like to avoid.)

-- 
Garry T. Williams

[Sérgio Basto]

On Mon, 2024-03-18 at 16:17 -0400, Garry T. Williams wrote:
>  On Wednesday, February 7, 2024 4:06:46 AM EDT Kevin Kofler via devel
>  wrote:
>  > Garry T. Williams wrote:
>  > > I hope my report can be resolved before I am forced to use
>  > > Wayland.
>  > 
>  > You will not be forced to use Wayland. Stay tuned.
>  
>  In an effort to test a Wayland bug I reported upstream, I upgraded my
>  laptop to f40.  (I am holding off on upgrading my workstation.)  My
>  reported bug is still there, but here I am without x11.  I installed
>  kwin-x11.  My login screen no longer offers to run it instead of
>  kwin-wayland.   Is there a way to run x11 on f40?  (There are still
>  several annoying bugs in Wayland that I would like to avoid.)
>   
 "kwin-wayland replaces kwin-x11 , on upgrade" → When upgrading to
Fedora 40

you may reinstall the package, it will not be obsoleted anymore.


I don't agree with this behavior 


-- 
Sérgio M. B.

[Garry T. Williams]

On Monday, March 18, 2024 4:46:01 PM EDT Sérgio Basto wrote:
>  On Mon, 2024-03-18 at 16:17 -0400, Garry T. Williams wrote:
>  > On Wednesday, February 7, 2024 4:06:46 AM EDT Kevin Kofler via devel
>  > wrote:
>  > > Garry T. Williams wrote:
>  > > > I hope my report can be resolved before I am forced to use
>  > > > Wayland.
>  > > 
>  > > You will not be forced to use Wayland. Stay tuned.
>  > 
>  > In an effort to test a Wayland bug I reported upstream, I upgraded my
>  > laptop to f40.  (I am holding off on upgrading my workstation.)  My
>  > reported bug is still there, but here I am without x11.  I installed
>  > kwin-x11.  My login screen no longer offers to run it instead of
>  > kwin-wayland.   Is there a way to run x11 on f40?  (There are still
>  > several annoying bugs in Wayland that I would like to avoid.)
>  
>   "kwin-wayland replaces kwin-x11 , on upgrade" → When upgrading to
>  Fedora 40
>  
>  you may reinstall the package, it will not be obsoleted anymore.
>  
>  I don't agree with this behavior  
OK, but how do I run kwin-x11 instead of -wayland?

-- 
Garry T. Williams

[Allan]

På Tue, 19 Mar 2024 09:09:26 -0400
"Garry T. Williams" <gtwilliams(a)gmail.com&gt; skrev:
>  On Monday, March 18, 2024 4:46:01 PM EDT Sérgio Basto wrote:
>  > On Mon, 2024-03-18 at 16:17 -0400, Garry T. Williams wrote:  
>  > > On Wednesday, February 7, 2024 4:06:46 AM EDT Kevin Kofler via
>  > > devel wrote:  
>  > > > Garry T. Williams wrote:  
>  > > > > I hope my report can be resolved before I am forced to use
>  > > > > Wayland.  
>  > > > 
>  > > > You will not be forced to use Wayland. Stay tuned.  
>  > > 
>  > > In an effort to test a Wayland bug I reported upstream, I
>  > > upgraded my laptop to f40.  (I am holding off on upgrading my
>  > > workstation.)  My reported bug is still there, but here I am
>  > > without x11.  I installed kwin-x11.  My login screen no longer
>  > > offers to run it instead of kwin-wayland.   Is there a way to run
>  > > x11 on f40?  (There are still several annoying bugs in Wayland
>  > > that I would like to avoid.)  
>  > 
>  >  "kwin-wayland replaces kwin-x11 , on upgrade" → When upgrading to
>  > Fedora 40
>  > 
>  > you may reinstall the package, it will not be obsoleted anymore.
>  > 
>  > I don't agree with this behavior   
>  
>  OK, but how do I run kwin-x11 instead of -wayland?
>   
You need plasma-workspace-x11  too.

[Sérgio Basto]

On Tue, 2024-03-19 at 14:22 +0100, Allan via devel wrote:
>  På Tue, 19 Mar 2024 09:09:26 -0400
>  "Garry T. Williams" <gtwilliams(a)gmail.com&gt; skrev:
>  > On Monday, March 18, 2024 4:46:01 PM EDT Sérgio Basto wrote:
>  > > On Mon, 2024-03-18 at 16:17 -0400, Garry T. Williams wrote:  
>  > > > On Wednesday, February 7, 2024 4:06:46 AM EDT Kevin Kofler via
>  > > > devel wrote:  
>  > > > > Garry T. Williams wrote:  
>  > > > > > I hope my report can be resolved before I am forced to use
>  > > > > > Wayland.  
>  > > > > 
>  > > > > You will not be forced to use Wayland. Stay tuned.  
>  > > > 
>  > > > In an effort to test a Wayland bug I reported upstream, I
>  > > > upgraded my laptop to f40.  (I am holding off on upgrading my
>  > > > workstation.)  My reported bug is still there, but here I am
>  > > > without x11.  I installed kwin-x11.  My login screen no longer
>  > > > offers to run it instead of kwin-wayland.   Is there a way to
>  > > > run
>  > > > x11 on f40?  (There are still several annoying bugs in Wayland
>  > > > that I would like to avoid.)  
>  > > 
>  > >  "kwin-wayland replaces kwin-x11 , on upgrade" → When upgrading
>  > > to
>  > > Fedora 40
>  > > 
>  > > you may reinstall the package, it will not be obsoleted anymore.
>  > > 
>  > > I don't agree with this behavior   
>  > 
>  > OK, but how do I run kwin-x11 instead of -wayland?
>  > 
>  
>  You need plasma-workspace-x11  too. 

After reinstall kwin-x11 and plasma-workspace-x11 , in desktop display
manager (for example sddm) you should have the option to login in
plasma-x11 


-- 
Sérgio M. B.

[Garry T. Williams]

On Tuesday, March 19, 2024 9:22:23 AM EDT Allan via devel wrote:
>  > OK, but how do I run kwin-x11 instead of -wayland?
>  
>  You need plasma-workspace-x11  too. 
Thanks.  That did it.

-- 
Garry T. Williams

[Kevin Kofler]

Allan via devel wrote:
>  You need plasma-workspace-x11  too. 
Note that plasma-workspace-x11 requires kwin-x11, so you do not explicitly 
have to install kwin-x11, only plasma-workspace-x11 (though of course it 
does not hurt to install kwin-x11 explicitly). plasma-workspace-x11 is the 
main package of the two, not kwin-x11.

plasma-workspace-x11 contains the session .desktop file and the startplasma-
x11 executable. kwin-x11 contains the kwin_x11 executable which is run (and 
hence required) by startplasma-x11.

        Kevin Kofler

[Steve Cossette]

That’s just kmail though. I have a similar issue, but kmail is just plain
broken in plasma 6 right now.

On Tue, Feb 6, 2024 at 11:08 PM Garry T. Williams <gtwilliams(a)gmail.com&gt;
wrote:

>  On Tuesday, 30 January 2024 08:07:25 EST Richard W.M. Jones wrote:
>  > On Tue, Jan 30, 2024 at 12:47:44PM +0000, Sérgio Basto wrote:
>  > > Link to the FESCo ticket: https://pagure.io/fesco/issue/3165
>  > >
>  > > and I'm very upset
>  >
>  > Assume best intent first of all.
>
>  I quit trying to use Wayland a long time ago because of the various
>  bugs.  When I saw this thread, I decided I better get ready and logged
>  out/in Plasma Wayland.
>
>  OK, I can live with windows that don't remember their geometry from
>  last session.  And I don't really have to have that last session
>  remembered and restored.  But...
>
>  I went to compose an E-mail message using kmail and its composer
>  window and noticed it was broken.[*]  I couldn't even find a bug
>  report about this.  I fear it's because many others just ignored the
>  various bugs and went back to using X11.
>
>  I hope my report can be resolved before I am forced to use Wayland.  I
>  understand that I am late to the party because I just ignored this for
>  so long.
>
>
>  _____________________
>  [*] https://bugs.kde.org/show_bug.cgi?id=480984
>
>  --
>  Garry T. Williams
>
>
>  --
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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/[e-mail]
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue
>

[Marc Deop i Argemí]

On Wednesday, 7 February 2024 05:07:28 CET Garry T. Williams wrote:
>  I went to compose an E-mail message using kmail and its composer
>  window and noticed it was broken.[*]  I couldn't even find a bug
>  report about this.  I fear it's because many others just ignored the
>  various bugs and went back to using X11. 
Thank you for taking a proactive approach Garry!

[Mattia Verga]

Il 30/01/24 13:47, Sérgio Basto ha scritto:
>  Link to the FESCo ticket: https://pagure.io/fesco/issue/3165
>
>  and I'm very upset
>  
I tried to read all the backward discussion and, if I'm correct, the 
point is that having the -x11 packages in Fedora official repositories 
would make "official" that KDE maintainers would have to avoid breaking 
those packages when making upgrades and so that would need more work. 
Their proposal to have the -x11 packages in a specific COPR repository, 
which wouldn't be official, would avoid that extra work, which was one 
of the reason because they decided to drop X11.

The COPR solution seems better for me for both parties: kde-sig folks 
wouldn't have to bother with X11 anymore, while -x11 maintainers could 
avoid unexpected breakage by bumping Epoch of the package in COPR and 
rebuild the full KDE Plasma stack there.

However, if the breakage could happen only one way, e.g. a KDE Plasma 
update will possibly break -x11 packages, but no -x11 package could 
break the "official" Wayland implementation, I'm for allowing the -x11 
packages in the main repos. I see no other reason why FESCO should block 
-x11 packages in the main repo, if a software is under an allowed 
license and doesn't harm the main system we should not refuse its packaging.

Mattia

[Steve Cossette]

On 2024-01-30 12:45 p.m., Mattia Verga via devel wrote:
>  Il 30/01/24 13:47, Sérgio Basto ha scritto:
> > Link to the FESCo ticket: https://pagure.io/fesco/issue/3165
> >
> > and I'm very upset
> >
>  I tried to read all the backward discussion and, if I'm correct, the
>  point is that having the -x11 packages in Fedora official repositories
>  would make "official" that KDE maintainers would have to avoid breaking
>  those packages when making upgrades and so that would need more work.
>  Their proposal to have the -x11 packages in a specific COPR repository,
>  which wouldn't be official, would avoid that extra work, which was one
>  of the reason because they decided to drop X11.
>
>  The COPR solution seems better for me for both parties: kde-sig folks
>  wouldn't have to bother with X11 anymore, while -x11 maintainers could
>  avoid unexpected breakage by bumping Epoch of the package in COPR and
>  rebuild the full KDE Plasma stack there.
>
>  However, if the breakage could happen only one way, e.g. a KDE Plasma
>  update will possibly break -x11 packages, but no -x11 package could
>  break the "official" Wayland implementation, I'm for allowing the -x11
>  packages in the main repos. I see no other reason why FESCO should block
>  -x11 packages in the main repo, if a software is under an allowed
>  license and doesn't harm the main system we should not refuse its packaging.
>
>  Mattia
>
>  --
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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/[e-mail]
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
That about sums it up, yes.


By the way, my name is Steve Cossette and I'm also one of the members of 
the KDE SiG. If the packages are accepted under the sole condition that 
it does not block the main KDE releases, then from a technical 
standpoint I'm happy with this.

The issue I am more worried now is from a user experience standpoint: if 
they need support, they will have to jump through hoops to get to the 
proper party (You know how things go sometimes -- some fedora packages 
are not updated as often as you'd like).

But aside from that, I don't have any problems with the ideas I saw 
posted here. I just sincerely hope this does not come back to bite us...

[Kevin Kofler]

Mattia Verga via devel wrote:
>  However, if the breakage could happen only one way, e.g. a KDE
> Plasma
>  update will possibly break -x11 packages, but no -x11 package could
>  break the "official" Wayland implementation, I'm for allowing the -x11
>  packages in the main repos. I see no other reason why FESCO should block
>  -x11 packages in the main repo, if a software is under an allowed
>  license and doesn't harm the main system we should not refuse its
>  packaging. 
By their nature, I do not see how the -x11 packages can possibly break the 
Wayland implementation. To do so, they would have to be either required or 
recommended by, or supplement or obsolete one of the "official" packages 
(because otherwise, users of the "official" packages will not have or get 
those packages even installed at all, as, at the latest, the upgrade to 
Fedora 40 will have obsoleted them). That is not currently the case (neither 
the Requires/Recommends scenario nor the Supplements/Obsoletes one), and I 
do not see that ever changing, as that would require a major blunder or a 
deliberate sabotage act by one of the involved parties. And then it would 
take an additional blunder for the package that gets accidentally installed 
to actually break something (except in the Obsoletes case if it accidentally 
obsoletes an essential package).

        Kevin Kofler

[Steve Cossette]

So, if you all don't mind, I'd like to steer this discussion in a slightly
different way:

What *is* the definition of a Fedora Change Proposal?

I was under the impression it was an announcement of intent by the
maintainers of a specific subset of the fedora project to "change"
something. Once said announcement has been discussed publicly, Fesco (Sorry
if the capitals are incorrect) discusses it internally (albeit, publicly)
and either blocks or approves the change, making it official.

*(Please note: The following paragraphs will use "we" as a pronoun which is
intended to be the Fedora project as a whole)*

Once approved, we announced our intent to drop X11 from the KDE spin of
Fedora. That announcement has gained traction everywhere, got publicized
and everything. As Neal Gompa also stated, it has already caused some
substantial development effort upstream to effectively iron out the rough
edges of many of the problems, with what I assume is more to come.

My fear is that, while those x11 libraries/runtimes/... *would* indeed no
longer be maintained by the KDE sig, we would basically just be partially
rolling back that initial proposal. And the quality of said packages would
also maybe suffer from them being updated separately, which might also
reflect poorly on us (*again, in this context, "us" = the Fedora Project)*.

It would also introduce a precedent: What if later a proposal is made to
remove some old drivers from, let's say, the kernel, and someone decides to
package it, undermining the general efforts of that proposal?

Hopefully I'm making sense. Writing this 30mins after waking up might not
have helped. What I'm trying to say basically is, I get that for some
legacy nvidia users the Wayland experience may not be optimal. But will it
*ever* be? Does that mean we can never drop x11? Will anyone ever update
those legacy nvidia drivers? *Could they be?*

Le mar. 30 janv. 2024, à 07 h 48, Sérgio Basto <sergio(a)serjux.com&gt; a écrit :

>  Link to the FESCo ticket: https://pagure.io/fesco/issue/3165
>
>  and I'm very upset
>
>  --
>  Sérgio M. B.
>  --
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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/[e-mail]
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue
>

[Naheem Zaffar]

Another option is to allow the x11-compatible packages but as a clearly
forked desktop with a clearly different name

On Thu, 1 Feb 2024, 12:10 Steve Cossette, <farchord(a)gmail.com&gt; wrote:

>  So, if you all don't mind, I'd like to steer this discussion
> in a slightly
>  different way:
>
>  What *is* the definition of a Fedora Change Proposal?
>
>  I was under the impression it was an announcement of intent by the
>  maintainers of a specific subset of the fedora project to "change"
>  something. Once said announcement has been discussed publicly, Fesco (Sorry
>  if the capitals are incorrect) discusses it internally (albeit, publicly)
>  and either blocks or approves the change, making it official.
>
>  *(Please note: The following paragraphs will use "we" as a pronoun which
>  is intended to be the Fedora project as a whole)*
>
>  Once approved, we announced our intent to drop X11 from the KDE spin of
>  Fedora. That announcement has gained traction everywhere, got publicized
>  and everything. As Neal Gompa also stated, it has already caused some
>  substantial development effort upstream to effectively iron out the rough
>  edges of many of the problems, with what I assume is more to come.
>
>  My fear is that, while those x11 libraries/runtimes/... *would* indeed no
>  longer be maintained by the KDE sig, we would basically just be partially
>  rolling back that initial proposal. And the quality of said packages would
>  also maybe suffer from them being updated separately, which might also
>  reflect poorly on us (*again, in this context, "us" = the Fedora Project)*
>  .
>
>  It would also introduce a precedent: What if later a proposal is made to
>  remove some old drivers from, let's say, the kernel, and someone decides to
>  package it, undermining the general efforts of that proposal?
>
>  Hopefully I'm making sense. Writing this 30mins after waking up might not
>  have helped. What I'm trying to say basically is, I get that for some
>  legacy nvidia users the Wayland experience may not be optimal. But will it
>  *ever* be? Does that mean we can never drop x11? Will anyone ever update
>  those legacy nvidia drivers? *Could they be?*
>
>  Le mar. 30 janv. 2024, à 07 h 48, Sérgio Basto <sergio(a)serjux.com&gt; a
>  écrit :
>
> > Link to the FESCo ticket: https://pagure.io/fesco/issue/3165
> >
> > and I'm very upset
> >
> > --
> > Sérgio M. B.
> > --
> > _______________________________________________
> > devel mailing list -- devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> > 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/[e-mail]
> > Do not reply to spam, report it:
> > https://pagure.io/fedora-infrastructure/new_issue
> >
>  --
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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/[e-mail]
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue
>

[Sérgio Basto]

On Thu, 2024-02-01 at 07:08 -0500, Steve Cossette wrote:
>  So, if you all don't mind, I'd like to steer this discussion
> in a
>  slightly different way: 
>  
>  What is the definition of a Fedora Change Proposal? 
Proposal was not accepted by many members of the community try accept
that .


>  I was under the impression it was an announcement of intent by the
>  maintainers of a specific subset of the fedora project to "change"
>  something. Once said announcement has been discussed publicly, Fesco
>  (Sorry if the capitals are incorrect) discusses it internally
>  (albeit, publicly) and either blocks or approves the change, making
>  it official.
>  
>  (Please note: The following paragraphs will use "we" as a pronoun
>  which is intended to be the Fedora project as a whole)
>  
>  Once approved, we announced our intent to drop X11 from the KDE spin
>  of Fedora. That announcement has gained traction everywhere, got
>  publicized and everything. As Neal Gompa also stated, it has already
>  caused some substantial development effort upstream to effectively
>  iron out the rough edges of many of the problems, with what I assume
>  is more to come.
>  
>  My fear is that, while those x11 libraries/runtimes/... would indeed
>  no longer be maintained by the KDE sig, we would basically just be
>  partially rolling back that initial proposal. And the quality of said
>  packages would also maybe suffer from them being updated separately,
>  which might also reflect poorly on us (again, in this context, "us" =
>  the Fedora Project). 
First, KDE SIG people are not the only persons that support and
maintain KDE , I'm maintainer of smb4k , kdenlive, kwave , smplayer and
more packages related with KDE and Qt .

The problem is not KDE SIG not support X11, the problem is KDE SIG want
drop X11 and force user to use wayland .

The other problem is not reach to an agreement with some members of KDE
SIG , which they think that can impose his decisions .

>  
>  It would also introduce a precedent: What if later a proposal is made
>  to remove some old drivers from, let's say, the kernel, and someone
>  decides to package it, undermining the general efforts of that
>  proposal?
>  
>  Hopefully I'm making sense. Writing this 30mins after waking up might
>  not have helped. What I'm trying to say basically is, I get that for
>  some legacy nvidia users the Wayland experience may not be optimal.
>  But will it ever be? Does that mean we can never drop x11? Will
>  anyone ever update those legacy nvidia drivers? Could they be?
>  
>  Le mar. 30 janv. 2024, à 07 h 48, Sérgio Basto <sergio(a)serjux.com&gt; a
>  écrit :
>  > Link to the FESCo ticket: https://pagure.io/fesco/issue/3165
>  > 
>  > and I'm very upset 
>  > 
>  > --
>  > _______________________________________________
>  > devel mailing list -- devel(a)lists.fedoraproject.org
>  > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  > 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/[e-mail]
>  > Do not reply to spam, report it:
>  > https://pagure.io/fedora-infrastructure/new_issue 
-- 
Sérgio M. B.

[Steve Cossette]

On 2024-02-01 8:18 a.m., Sérgio Basto wrote:
>  On Thu, 2024-02-01 at 07:08 -0500, Steve Cossette wrote:
> > So, if you all don't mind, I'd like to steer this discussion in a
> > slightly different way:
> >
> > What is the definition of a Fedora Change Proposal?
>  Proposal was not accepted by many members of the community try accept
>  that . 
A proposal will always have opposing members, that's how it always is 
for everything in life. That's why Fesco then makes a judgement call and 
decides on what to do. But I do believe your reply was besides the point.
> > I was under the impression it was an announcement of intent by the
> > maintainers of a specific subset of the fedora project to "change"
> > something. Once said announcement has been discussed publicly, Fesco
> > (Sorry if the capitals are incorrect) discusses it internally
> > (albeit, publicly) and either blocks or approves the change, making
> > it official.
> >
> > (Please note: The following paragraphs will use "we" as a pronoun
> > which is intended to be the Fedora project as a whole)
> >
> > Once approved, we announced our intent to drop X11 from the KDE spin
> > of Fedora. That announcement has gained traction everywhere, got
> > publicized and everything. As Neal Gompa also stated, it has already
> > caused some substantial development effort upstream to effectively
> > iron out the rough edges of many of the problems, with what I assume
> > is more to come.
> >
> > My fear is that, while those x11 libraries/runtimes/... would indeed
> > no longer be maintained by the KDE sig, we would basically just be
> > partially rolling back that initial proposal. And the quality of said
> > packages would also maybe suffer from them being updated separately,
> > which might also reflect poorly on us (again, in this context, "us" =
> > the Fedora Project).
>  First, KDE SIG people are not the only persons that support and
>  maintain KDE , I'm maintainer of smb4k , kdenlive, kwave , smplayer and
>  more packages related with KDE and Qt .
>
>  The problem is not KDE SIG not support X11, the problem is KDE SIG want
>  drop X11 and force user to use wayland .
>
>  The other problem is not reach to an agreement with some members of KDE
>  SIG , which they think that can impose his decisions . 
Yes, and we (Again, as-in, the Fedora community) deeply appreciates you 
for your contributions. I was, again, trying to make a big picture 
comment about the whole thing, not as an attack on you specifically.

And yes, that /is/ the whole point: We want to foster the use of 
Wayland, to increase it's adoption, to force people using it to hit 
snags along the road and fill tickets so those issues can be fixed.

You'd be amazed how many issues I've seen being fixed in the last couple 
months.

> > It would also introduce a precedent: What if later a proposal is made
> > to remove some old drivers from, let's say, the kernel, and someone
> > decides to package it, undermining the general efforts of that
> > proposal?
> >
> > Hopefully I'm making sense. Writing this 30mins after waking up might
> > not have helped. What I'm trying to say basically is, I get that for
> > some legacy nvidia users the Wayland experience may not be optimal.
> > But will it ever be? Does that mean we can never drop x11? Will
> > anyone ever update those legacy nvidia drivers? Could they be?
> >
> > Le mar. 30 janv. 2024, à 07 h 48, Sérgio Basto<sergio(a)serjux.com>  a
> > écrit :
> >> Link to the FESCo ticket:https://pagure.io/fesco/issue/3165
> >>
> >> and I'm very upset
> >>
> >> --
> >> _______________________________________________
> >> devel mailing list --devel(a)lists.fedoraproject.org
> >> To unsubscribe send an email todevel-leave(a)lists.fedoraproject.org
> >> 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/[e-mail]
> >> Do not reply to spam, report it:
> >> https://pagure.io/fedora-infrastructure/new_issue

[pgnd]

my non-technical, business-focused $0.02.

there's a great deal of reasonable discussion here.
there are technical & resource reasons for & against each change.

this very discussion sows confusion, particularly with F40 "just around the next
corner".
nonetheless, it needs to be had.

the fact remains, Wayland functionality and X11 functionality are not at functional
parity/equivalence.
and may never be.

to my cursory count, there are currently four constituencies in this discussion:

	Fesco/FedoraProject
	Fedora community
	Fedora KDE SIG
	KDE upstream

, each with varying degrees of pro- & con- X11-continued-support.

resources are limited.
at EACH of those constituencies. including end users' ...
and EACH has different priorities, with different weights.

'expectations of' any given constituency simply will not fly in community-driven
work.

personally, i'm not at all in support of Fedora's wayland-only stance --
particularly as it's out-of-timeline-sync with KDE upstream's policy.

that said, Fedora already feels like it's fraying at the seams from lack of resource.
and for project health, if the project decision's been made to be wayland-only, then
that should be a clean break.
any additional/continuing work should be allowed -- it's community -- but kept as
separate as possible from official release.

i.e., rip the bandaid off, KISS, and don't dilute.

for me?
there's in-X11/not-yet-in-Wayland functionality that we've come to depend on.
loss of that functionality is a business cost, here.  planning, support, end-user sat,
etc.
we've done our own math & risk assessment ... valid only for us, of course.

for many users, fedora/KDE COPR-based solutions will work. for awhile.
but for a fair number of others, we're pulling the plug and switching platforms.

that's not a criticism.  or a technical argument.
that's simply our ack of our current & forseeable business needs.
here.

[Steve Cossette]

Hello Pgnd,

I honestly do appreciate your point of view. Especially from a business
owner standpoint. I do manage small business servers, and I feel you in
that regard.

I do have to also applaud your nerves of steel though, using Fedora as a
server in a business environment, to me anyway, always felt ill-advised as
things tend to take rough 90 degree turns in Fedora which can often cause
breakages in some server scenarios and stuff (The F40 mysql change comes to
mind). That'S why most people I know that use Linux for server hosting tend
to use a more 'stagnant' distro (i.e. Rocky, Alma, Debian, ...).

But I feel like I'm going off subject. I also think you are right, the KDE
COPR-solution would work as long as it is documented somewhere. We could
simply put it in the Fedora docs page, but also clearly note that those
packages are not supported, but will be updated until the underlying
frameworks (e.g. Xorg, or when the KDE foundation no longer supports Xorg,
whichever comes first) are no longer available.

Le jeu. 1 févr. 2024, à 09 h 05, pgnd <pgnd(a)dev-mail.net&gt; a écrit :

>  my non-technical, business-focused $0.02.
>
>  there's a great deal of reasonable discussion here.
>  there are technical & resource reasons for & against each change.
>
>  this very discussion sows confusion, particularly with F40 "just around
>  the next corner".
>  nonetheless, it needs to be had.
>
>  the fact remains, Wayland functionality and X11 functionality are not at
>  functional parity/equivalence.
>  and may never be.
>
>  to my cursory count, there are currently four constituencies in this
>  discussion:
>
>          Fesco/FedoraProject
>          Fedora community
>          Fedora KDE SIG
>          KDE upstream
>
>  , each with varying degrees of pro- & con- X11-continued-support.
>
>  resources are limited.
>  at EACH of those constituencies. including end users' ...
>  and EACH has different priorities, with different weights.
>
>  'expectations of' any given constituency simply will not fly in
>  community-driven work.
>
>  personally, i'm not at all in support of Fedora's wayland-only stance --
>  particularly as it's out-of-timeline-sync with KDE upstream's policy.
>
>  that said, Fedora already feels like it's fraying at the seams from lack
>  of resource.
>  and for project health, if the project decision's been made to be
>  wayland-only, then that should be a clean break.
>  any additional/continuing work should be allowed -- it's community -- but
>  kept as separate as possible from official release.
>
>  i.e., rip the bandaid off, KISS, and don't dilute.
>
>  for me?
>  there's in-X11/not-yet-in-Wayland functionality that we've come to depend
>  on.
>  loss of that functionality is a business cost, here.  planning, support,
>  end-user sat, etc.
>  we've done our own math & risk assessment ... valid only for us, of course.
>
>  for many users, fedora/KDE COPR-based solutions will work. for awhile.
>  but for a fair number of others, we're pulling the plug and switching
>  platforms.
>
>  that's not a criticism.  or a technical argument.
>  that's simply our ack of our current & forseeable business needs.
>  here.
>  --
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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/[e-mail]
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue
>

[Peter Boy]

Sorry, a bit off-topic here, but nevertheless:

>  Am 01.02.2024 um 15:14 schrieb Steve Cossette
> <farchord(a)gmail.com&gt;:
>  
>  Hello Pgnd,
>  
>  I honestly do appreciate your point of view. Especially from a business owner standpoint.
> I do manage small business servers, and I feel you in that regard.
>  
>  I do have to also applaud your nerves of steel though, using Fedora as a server in a
> business environment, to me anyway, always felt ill-advised as things tend to take rough
> 90 degree turns in Fedora which can often cause breakages in some server scenarios and
> stuff (The F40 mysql change comes to mind). 

Hello Steve and hello Pgnd,

I would like to ask you (and invite you) to discuss your "take rough 90 degree turns“
assessment for Fedora Server on Fedora Server list (and hopefully diminish your need for
nerves of steel). I rather hear sometimes a kind of disappointment (or rebuke) about
Fedora Server, that it is boring and it changes too little, no excitement, no surprise,
too little new, everything just works as it has always worked, ... That kind of thing,
just boring.

We aim to avoid „90 degree turns“ and disruption and proof to be able to provide the
latest functionality of software services in a stable and reliable environment without
much delay and, above all, without disruption. And if I look at our download statistics,
an increasing number of admins seem to like it.

Your example about the mysql change does not seem to me to be in any way as significant as
the decision about KDE and Xorg. And does not represent a disruption, but rather an
evolution. 


Would really like to discuss with you about recent 90 degree turns (I’m not aware of any
in the last 2-3 years) and how to avoid it.



--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
PBoy(a)fedoraproject.org <mailto:[e-mail]>

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast

[Steve Cossette]

On 2024-02-01 10:27 a.m., Peter Boy wrote:
>  Sorry, a bit off-topic here, but nevertheless:
>
> > Am 01.02.2024 um 15:14 schrieb Steve Cossette <farchord(a)gmail.com&gt;:
> >
> > Hello Pgnd,
> >
> > I honestly do appreciate your point of view. Especially from a 
> > business owner standpoint. I do manage small business servers, and I 
> > feel you in that regard.
> >
> > I do have to also applaud your nerves of steel though, using Fedora 
> > as a server in a business environment, to me anyway, always felt 
> > ill-advised as things tend to take rough 90 degree turns in Fedora 
> > which can often cause breakages in some server scenarios and stuff 
> > (The F40 mysql change comes to mind).
>
>
>  Hello Steve and hello Pgnd,
>
>  I would like to ask you (and invite you) to discuss your "take rough 
>  90 degree turns“ assessment for Fedora Server on Fedora Server list 
>  (and hopefully diminish your need for nerves of steel). I rather hear 
>  sometimes a kind of disappointment (or rebuke) about Fedora Server, 
>  that it is boring and it changes too little, no excitement, no 
>  surprise, too little new, everything just works as it has always 
>  worked, ... That kind of thing, just boring.
>
>  We aim to avoid „90 degree turns“ and disruption and proof to be able 
>  to provide the latest functionality of software services in a stable 
>  and reliable environment without much delay and, above all, without 
>  disruption. And if I look at our download statistics, an increasing 
>  number of admins seem to like it.
>
>  Your example about the mysql change does not seem to me to be in any 
>  way as significant as the decision about KDE and Xorg. And does not 
>  represent a disruption, but rather an evolution.
>
>
>  Would really like to discuss with you about recent 90 degree turns 
>  (I’m not aware of any in the last 2-3 years) and how to avoid it.
>
>
>
>  --
>  Peter Boy
>  https://fedoraproject.org/wiki/User:Pboy
>  PBoy(a)fedoraproject.org
>
>  Timezone: CET (UTC+1) / CEST (UTC+2)
>
>  Fedora Server Edition Working Group member
>  Fedora Docs team contributor and board member
>  Java developer and enthusiast
>
>
>
>
>
>
>  --
>  _______________________________________________
>  devel mailing list --devel(a)lists.fedoraproject.org
>  To unsubscribe send an email todevel-leave(a)lists.fedoraproject.org
>  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/[e-mail]...
>  Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue 
Will do!

[Peter Boy]

>  Am 01.02.2024 um 16:47 schrieb Steve Cossette
> <farchord(a)gmail.com&gt;:
>  
>  On 2024-02-01 10:27 a.m., Peter Boy wrote:
> > 
> > Sorry, a bit off-topic here, but nevertheless:
> > 
> >> Am 01.02.2024 um 15:14 schrieb Steve Cossette <farchord(a)gmail.com&gt;:
> >>  
> > 
> > 
>  Will do! 
Thanks, see you there


--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
PBoy(a)fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast

[Kevin Kofler]

Steve Cossette wrote:
>  But I feel like I'm going off subject. I also think you are
> right, the KDE
>  COPR-solution would work as long as it is documented somewhere. We could
>  simply put it in the Fedora docs page, but also clearly note that those
>  packages are not supported, but will be updated until the underlying
>  frameworks (e.g. Xorg, or when the KDE foundation no longer supports Xorg,
>  whichever comes first) are no longer available. 
Unlike you ("you" = the KDE SIG), I actually believe I can probably keep my 
*-x11 packages on life support for some time even if and when KDE upstream 
drops their X11 support. Kinda like I have been doing for, e.g., Blogilo. 
Realistic would be until the release of Plasma 7, unless some Plasma 6.x 
introduces major changes that make it impractical. But I hope this is not 
going to be a concern for Fedora 40.

        Kevin Kofler

[Gary Buhrmaster]

On Fri, Feb 2, 2024 at 1:51 AM Kevin Kofler via devel
<devel(a)lists.fedoraproject.org&gt; wrote:

>  Unlike you ("you" = the KDE SIG), I actually believe I can
> probably keep my
>  *-x11 packages on life support for some time even if and when KDE upstream
>  drops their X11 support. Kinda like I have been doing for, e.g., Blogilo.
>  Realistic would be until the release of Plasma 7, unless some Plasma 6.x
>  introduces major changes that make it impractical. But I hope this is not
>  going to be a concern for Fedora 40. 
For something that has the potential to
impact KDE users that would choose to
remain on X11, I would absolutely hope
there is more than just you involved in
the effort (busses, and vacations, happen).

Having something like a KDE-X11-SIG
team (made up name), with a few known
active members, would probably go a long
way to reduce the concerns of others
regarding tracking (and taking) bugs, and
lack of timely updates, for something as
visible as the entire desktop.

[Kevin Kofler]

Gary Buhrmaster wrote:
>  For something that has the potential to
>  impact KDE users that would choose to
>  remain on X11, I would absolutely hope
>  there is more than just you involved in
>  the effort (busses, and vacations, happen).
>  
>  Having something like a KDE-X11-SIG
>  team (made up name), with a few known
>  active members, would probably go a long
>  way to reduce the concerns of others
>  regarding tracking (and taking) bugs, and
>  lack of timely updates, for something as
>  visible as the entire desktop. 
I welcome any comaintainers to the {kwin,plasma-workspace}-x11 packages (as 
long as they do not intend to abuse their access to retire the package 
without my agreement, of course). More helping hands = less work per person.

        Kevin Kofler

[Gary Buhrmaster]

On Sat, Feb 3, 2024 at 2:32 AM Kevin Kofler via devel
<devel(a)lists.fedoraproject.org&gt; wrote:
>  Gary Buhrmaster wrote:
>  > For something that has the potential to
>  > impact KDE users that would choose to
>  > remain on X11, I would absolutely hope
>  > there is more than just you involved in
>  > the effort (busses, and vacations, happen).
>  >
>  > Having something like a KDE-X11-SIG
>  > team (made up name), with a few known
>  > active members, would probably go a long
>  > way to reduce the concerns of others
>  > regarding tracking (and taking) bugs, and
>  > lack of timely updates, for something as
>  > visible as the entire desktop.
>
>  I welcome any comaintainers to the {kwin,plasma-workspace}-x11 packages (as
>  long as they do not intend to abuse their access to retire the package
>  without my agreement, of course). More helping hands = less work per person. 
So, just to be clear, and to eliminate any
possible misinterpretation, you are
stating this is a one-person show at
this time?

[Kevin Kofler]

Gary Buhrmaster wrote:
>  So, just to be clear, and to eliminate any
>  possible misinterpretation, you are
>  stating this is a one-person show at
>  this time? 
The Fedora package review policy states that the submitter automatically 
becomes the point of contact of the submitted packages. So, since I 
submitted those packages, if they are approved, I will be the one who will 
have to approve any comaintainers. By default, there will be none, which is 
just how the policy works.

I believe from the discussions that there are already at least 1 or 2 people 
interested in comaintaining, but ultimately it is those people who will have 
to explicitly sign up for it. I obviously cannot announce somebody as a 
comaintainer without the alleged comaintainer's permission.

Any interested people can already request comaintainership now (e.g., by 
replying to this mail), and I will almost certainly grant it (though I will 
have reservations about some specific types of requests, such as blanket 
admin permissions for the entire @kde-sig group), but of course contingent 
on the packages being approved (i.e., the FESCo hold on them being lifted, 
and the reviews subsequently passing), because there is nothing to 
comaintain before that point and also nowhere I can fill in those 
comaintainership requests before the dist-git Pagure repository is created.

        Kevin Kofler

[Steven A. Falco]

On 2/3/24 01:12 AM, Kevin Kofler via devel wrote:
>  Any interested people can already request comaintainership now (e.g.,
> by
>  replying to this mail), and I will almost certainly grant it (though I will
>  have reservations about some specific types of requests, such as blanket
>  admin permissions for the entire @kde-sig group), but of course contingent
>  on the packages being approved (i.e., the FESCo hold on them being lifted,
>  and the reviews subsequently passing), because there is nothing to
>  comaintain before that point and also nowhere I can fill in those
>  comaintainership requests before the dist-git Pagure repository is created. 
I am interested, FAS: stevenfalco

[Marc Deop i Argemí]

On Friday, 2 February 2024 20:56:22 CET Gary Buhrmaster wrote:
>  regarding tracking (and taking) bugs, and
>  lack of timely updates, for something as
>  visible as the entire desktop. 
Here you are highlighting some of my (I speak for me, not the KDE SIG) main 
concerns:

- If a user decided to install the X11 package and has an issue: who do you 
think they are going to reach? who is gonna get the "bad publicity" for the 
issue? ( specially when we are forced to tell them we don't support X11...)

- As the packages stand right now, the KDE general updates will have to wait 
for the proposed packages to be updated by their maintainers or we will have 
to do the updates ourselves (which defeats completely the point of our change 
proposal).

Best regards,

Marc

[Adam Williamson]

On 2024-02-03 06:16, Marc Deop i Argemí wrote:
>  - As the packages stand right now, the KDE general updates will have
> to wait
>  for the proposed packages to be updated by their maintainers or we will have
>  to do the updates ourselves (which defeats completely the point of our change
>  proposal). 
Why? This is the part I don't understand. Can you explain it in more 
detail? Thanks.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net

[Marc Deop i Argemí]

On Saturday, 3 February 2024 17:52:42 CET Adam Williamson wrote:
>  Why? This is the part I don't understand. Can you explain it in
> more
>  detail? Thanks. 
If we update plasma-workspace and kwin we are likely gonna break binary 
compatibility with the proposed packages.

They will need to be rebuilt ala soname bump of sorts.

I understand this is no different than the aforementioned soname but it is 
certainly not a "standard" chain of dependencies.

Best regards,

Marc

[Dominique Martinet]

(Not involved in any way here so feel free to ignore most of what I'm
saying)

Marc Deop i Argemí wrote on Sat, Feb 03, 2024 at 03:16:47PM +0100:
>  - If a user decided to install the X11 package and has an issue: who
> do you 
>  think they are going to reach? who is gonna get the "bad publicity" for the 
>  issue? ( specially when we are forced to tell them we don't support X11...) 
I don't really understand this one -- why would they reach for the KDE
SIG specifically? What does "support" even mean in this context?


As a fedora user (not even using KDE), I don't care about SIGs, if I
have a problem I'll just open a bz against the package that gives me
trouble.
Now I'm sure some tickets will be open against KDE without specifying
they're using the X11 packages, but at least semi-automated bugs will
have a package list so it shouldn't be _that_ much trouble to just
reassign the bug to the x11 package if required (especially since x11 is
no longer selected by default and requires manual intervention to use,
I'd expect most users who care enough to report a bug to be aware of the
difference)

At this point it's no longer KDE SIG's problem -- it's whoever is
maintaining the package's role to follow up on that bz.
I haven't seen Kevin or anyone else say they'd just close the bugs as
"not my problem" -- x11 is still supported upstream so I'd expect
they'd
at least forward the bug there, if they don't look into it themselves
directly.

Also if you're concerend about the "publicity", for users who cannot run
on wayland yet for whatever reason (hardware, buggy drivers...) having
the possibility to use x11 at all is still going to be much better PR
than "nope sorry we don't want to spend time on X11 just suffer through
the wayland bugs" which is exactly how this will sound to them (yes I
can understand the reasons that were given up for this and rationalize
this a bit better, but this isn't how it'll look for someone with
problems)


Long story short, I agree with the "if someone wants to do it let them
do" stance.
I can't speak about your second point (delaying upgrades), but from what
I've read of this thread it doesn't seem like there'd be a huge delay if
some minimal communication is in place, and the suggesstion of having a
KDE X11 sig to ensure it's not just a single person also makes sense
(although if it's a single package just having multiple maintainers to
it sounds enough to me)

-- 
Dominique Martinet | Asmadeus

[pgnd]

> > Is there a way to see what gaps remain, which ones are being
> worked on, and which ones
> > will be declared "not a gap - won't fix"? 
>  I have a list of things I'm tracking. I've been reluctant to
> publish
>  it because people will think that it's some kind of "general Wayland
>  tracker" since I have no influence or impact on GNOME Wayland (which
>  is the one most people are concerned about). 
a not authoritative, but informative list for KDE + Wayland 'gaps' & issues,
from community,

	https://community.kde.org/Plasma/Wayland_Known_Significant_Issues

there's a more authoritative bug list @

	https://planet.kde.org/

	Bug fixes

		4 Very high priority Plasma bugs (same as last week). <Current list of bugs>
		32 15-minute Plasma bugs (down from 34 last week). <Current list of bugs>
		149 KDE bugs of all kinds fixed over last week. <Full list of bugs>


if, & how well, the 'gaps' list will map to the 'bug' list by either
'KDE 6' or Fedora40 release, remains to be seen

[Roberto Ragusa]

On 2/3/24 22:11, pgnd wrote:
> >> Is there a way to see what gaps remain, which ones are being
> worked on, and which ones
> >> will be declared "not a gap - won't fix"?
>  
> > I have a list of things I'm tracking. I've been reluctant to publish
> > it because people will think that it's some kind of "general Wayland
> > tracker" since I have no influence or impact on GNOME Wayland (which
> > is the one most people are concerned about).
>  
>  a not authoritative, but informative list for KDE + Wayland 'gaps' & issues,
> from community,
>  
>       https://community.kde.org/Plasma/Wayland_Known_Significant_Issues 
Wow, that really lowers my desire to attempt to use Wayland for KDE.

first line: "Save session doesn't work under Wayland"

after many other opened-for-years things I see:

"Window shading not supported for Wayland windows"

with no solution after 7 years.

Regards.

-- 
    Roberto Ragusa    mail at robertoragusa.it

[Steve Cossette]

On 2024-02-06 8:20 a.m., Roberto Ragusa wrote:
>  On 2/3/24 22:11, pgnd wrote:
> >>> Is there a way to see what gaps remain, which ones are being worked 
> >>> on, and which ones
> >>> will be declared "not a gap - won't fix"?
> >
> >> I have a list of things I'm tracking. I've been reluctant to publish
> >> it because people will think that it's some kind of "general Wayland
> >> tracker" since I have no influence or impact on GNOME Wayland (which
> >> is the one most people are concerned about).
> >
> > a not authoritative, but informative list for KDE + Wayland 'gaps' & 
> > issues, from community,
> >
> >      https://community.kde.org/Plasma/Wayland_Known_Significant_Issues
>
>  Wow, that really lowers my desire to attempt to use Wayland for KDE.
>
>  first line: "Save session doesn't work under Wayland"
>
>  after many other opened-for-years things I see:
>
>  "Window shading not supported for Wayland windows"
>
>  with no solution after 7 years.
>
>  Regards.
>  
To be fair, I see alot of projects that I filled tickets for have 
tickets open for years, that's not uncommon.


And many people want the feature that allows to save sessions, for KDE I 
believe we call that Session Restore, or Resuming session.


But to be fair as well, that doesn't exist on Windows (Windows can 
reopen the programs you are working on but it doesn't save what you were 
doing) and MacOS "kinda" has it? But if I remember well it had it's own 
share of issues.


Xorg I've been told has it, but each program has to support it.

[Kevin Kofler]

Steve Cossette wrote:
>  But to be fair as well, that doesn't exist on Windows (Windows
> can
>  reopen the programs you are working on but it doesn't save what you were
>  doing) 
And even that, it does not do automatically, it is an application feature to 
request this through the registry. (Something Wayland applications could in 
theory also due through XDG autostart or systemd user units, but in practice 
do not do, because application developers are used from X11 to this just 
working.)

>  Xorg I've been told has it, but each program has to support it.
Of course, saving and restoring the application state requires application 
support. But many desktop applications have that code already for X11 
session restore and it would probably only take a toolkit (Qt/GTK) update to 
pick up a Wayland protocol for this without the application having to do 
anything. (By the way, mobile or convergent applications are supposed to 
have support for this because Android requires it for power management, so 
there too, there is code that could likely be enabled with minimal effort, 
though it would probably need application code changes to bring it out of an 
Android-only code path if they do not already support this on X11.)

        Kevin Kofler

[Neal Gompa]

On Wed, Feb 7, 2024 at 11:12 PM Kevin Kofler via devel
<devel(a)lists.fedoraproject.org&gt; wrote:
>  Steve Cossette wrote:
>  > But to be fair as well, that doesn't exist on Windows (Windows can
>  > reopen the programs you are working on but it doesn't save what you were
>  > doing)
>
>  And even that, it does not do automatically, it is an application feature to
>  request this through the registry. (Something Wayland applications could in
>  theory also due through XDG autostart or systemd user units, but in practice
>  do not do, because application developers are used from X11 to this just
>  working.)
>
>  > Xorg I've been told has it, but each program has to support it.
>
>  Of course, saving and restoring the application state requires application
>  support. But many desktop applications have that code already for X11
>  session restore and it would probably only take a toolkit (Qt/GTK) update to
>  pick up a Wayland protocol for this without the application having to do
>  anything. (By the way, mobile or convergent applications are supposed to
>  have support for this because Android requires it for power management, so
>  there too, there is code that could likely be enabled with minimal effort,
>  though it would probably need application code changes to bring it out of an
>  Android-only code path if they do not already support this on X11.)
>  
The Wayland protocol in question is this one:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18

That said, even X11's version isn't widely supported. Typically,
support for this is plumbed through linking libSM, and GTK notably
does not use it. Qt does, of course.

This is one of the things I've had on my radar for quite some time.
macOS-style automatic relaunch of applications is slated upstream for
6.1: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3523

Support for the Wayland protocol will come after, but the combination
of the two approaches means that pretty much everything will be able
to relaunch as desired in some form on restart.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Steven A. Falco]

On 2/8/24 05:44 AM, Neal Gompa wrote:
>  The Wayland protocol in question is this one:
>  https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18
>  
>  That said, even X11's version isn't widely supported. Typically,
>  support for this is plumbed through linking libSM, and GTK notably
>  does not use it. Qt does, of course.
>  
>  This is one of the things I've had on my radar for quite some time.
>  macOS-style automatic relaunch of applications is slated upstream for
>  6.1: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3523
>  
>  Support for the Wayland protocol will come after, but the combination
>  of the two approaches means that pretty much everything will be able
>  to relaunch as desired in some form on restart. 
My approach on X11 is to have a script that launches the apps that I want, where I want
them placed, and of what size I want.  For example:

/usr/bin/konsole --qwindowgeometry 1757x1468+2614+0 &

But that doesn't work in wayland, so I wrote [0].

	Steve

[0] - https://bugzilla.redhat.com/show_bug.cgi?id=2239016

[Roberto Ragusa]

On 2/1/24 14:29, Steve Cossette wrote:

>  And yes, that /is/ the whole point: We want to foster the use of
> Wayland, to increase it's adoption, to force people using it to hit snags along the
> road and fill tickets so those issues can be fixed. 
"force people"
"hit snag"

With this kind of attitude, don't be surprised when people describe Fedora
as "the beta test" for Red Hat.

Regards.

-- 
    Roberto Ragusa    mail at robertoragusa.it

[Steve Cossette]

On 2024-02-01 11:21 a.m., Roberto Ragusa wrote:
>  On 2/1/24 14:29, Steve Cossette wrote:
>
> > And yes, that /is/ the whole point: We want to foster the use of 
> > Wayland, to increase it's adoption, to force people using it to hit 
> > snags along the road and fill tickets so those issues can be fixed.
>  "force people" "hit snag"
>
>  With this kind of attitude, don't be surprised when people describe 
>  Fedora
>  as "the beta test" for Red Hat.
>
>  Regards.
>  
When you think about it, we are!

Fedora Packages go to CentOS stream, which then go over to RHEL... It's 
well documented!

[Neal Gompa]

On Thu, Feb 1, 2024 at 4:21 PM Roberto Ragusa <mail(a)robertoragusa.it&gt; wrote:
>  On 2/1/24 14:29, Steve Cossette wrote:
>
>  > And yes, that /is/ the whole point: We want to foster the use of Wayland, to
> increase it's adoption, to force people using it to hit snags along the road and fill
> tickets so those issues can be fixed.
>  "force people" "hit snag"
>
>  With this kind of attitude, don't be surprised when people describe Fedora
>  as "the beta test" for Red Hat.
>  
To put it bluntly: KDE is not part of RHEL and Red Hat couldn't care
less about KDE. A "beta test" for Red Hat is pretty useless when it
has basically no impact for Red Hat, positively or negatively.

We are doing this because without doing so, the gaps will *never* be
identified to be fixed in the first place. And they *are* getting
fixed at a rapid clip.

And we've been using Wayland by default for Fedora KDE for the past
three years. This is the next step on that path.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Steven A. Falco]

On 2/1/24 11:28 AM, Neal Gompa wrote:
>  On Thu, Feb 1, 2024 at 4:21 PM Roberto Ragusa
> <mail(a)robertoragusa.it&gt; wrote:
> >
> > On 2/1/24 14:29, Steve Cossette wrote:
> >
> >> And yes, that /is/ the whole point: We want to foster the use of Wayland, to
> increase it's adoption, to force people using it to hit snags along the road and fill
> tickets so those issues can be fixed.
> > "force people" "hit snag"
> >
> > With this kind of attitude, don't be surprised when people describe Fedora
> > as "the beta test" for Red Hat.
> >
>  
>  To put it bluntly: KDE is not part of RHEL and Red Hat couldn't care
>  less about KDE. A "beta test" for Red Hat is pretty useless when it
>  has basically no impact for Red Hat, positively or negatively.
>  
>  We are doing this because without doing so, the gaps will *never* be
>  identified to be fixed in the first place. And they *are* getting
>  fixed at a rapid clip. 
I'd like to think that the gaps will be fixed, but it seems to me that because of
policy, some gaps (like apps controlling their own window placement) will never be fixed.

Is there a way to see what gaps remain, which ones are being worked on, and which ones
will be declared "not a gap - won't fix"?

	Steve

[Neal Gompa]

On Thu, Feb 1, 2024 at 4:40 PM Steven A. Falco <stevenfalco(a)gmail.com&gt; wrote:
>  On 2/1/24 11:28 AM, Neal Gompa wrote:
>  > On Thu, Feb 1, 2024 at 4:21 PM Roberto Ragusa <mail(a)robertoragusa.it&gt; wrote:
>  >>
>  >> On 2/1/24 14:29, Steve Cossette wrote:
>  >>
>  >>> And yes, that /is/ the whole point: We want to foster the use of Wayland, to
> increase it's adoption, to force people using it to hit snags along the road and fill
> tickets so those issues can be fixed.
>  >> "force people" "hit snag"
>  >>
>  >> With this kind of attitude, don't be surprised when people describe Fedora
>  >> as "the beta test" for Red Hat.
>  >>
>  >
>  > To put it bluntly: KDE is not part of RHEL and Red Hat couldn't care
>  > less about KDE. A "beta test" for Red Hat is pretty useless when it
>  > has basically no impact for Red Hat, positively or negatively.
>  >
>  > We are doing this because without doing so, the gaps will *never* be
>  > identified to be fixed in the first place. And they *are* getting
>  > fixed at a rapid clip.
>
>  I'd like to think that the gaps will be fixed, but it seems to me that because of
> policy, some gaps (like apps controlling their own window placement) will never be fixed.
>  
That is not necessarily true. For your example about window placement,
there is this:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests...

>  Is there a way to see what gaps remain, which ones are being worked
> on, and which ones will be declared "not a gap - won't fix"?
>  
I have a list of things I'm tracking. I've been reluctant to publish
it because people will think that it's some kind of "general Wayland
tracker" since I have no influence or impact on GNOME Wayland (which
is the one most people are concerned about).



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Neal Gompa]

On Thu, Feb 1, 2024 at 4:44 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  On Thu, Feb 1, 2024 at 4:40 PM Steven A. Falco <stevenfalco(a)gmail.com&gt; wrote:
>  >
>  > On 2/1/24 11:28 AM, Neal Gompa wrote:
>  > > On Thu, Feb 1, 2024 at 4:21 PM Roberto Ragusa <mail(a)robertoragusa.it&gt;
> wrote:
>  > >>
>  > >> On 2/1/24 14:29, Steve Cossette wrote:
>  > >>
>  > >>> And yes, that /is/ the whole point: We want to foster the use of
> Wayland, to increase it's adoption, to force people using it to hit snags along the
> road and fill tickets so those issues can be fixed.
>  > >> "force people" "hit snag"
>  > >>
>  > >> With this kind of attitude, don't be surprised when people describe
> Fedora
>  > >> as "the beta test" for Red Hat.
>  > >>
>  > >
>  > > To put it bluntly: KDE is not part of RHEL and Red Hat couldn't care
>  > > less about KDE. A "beta test" for Red Hat is pretty useless when it
>  > > has basically no impact for Red Hat, positively or negatively.
>  > >
>  > > We are doing this because without doing so, the gaps will *never* be
>  > > identified to be fixed in the first place. And they *are* getting
>  > > fixed at a rapid clip.
>  >
>  > I'd like to think that the gaps will be fixed, but it seems to me that because
> of policy, some gaps (like apps controlling their own window placement) will never be
> fixed.
>  >
>
>  That is not necessarily true. For your example about window placement,
>  there is this:
> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests...
>
>  > Is there a way to see what gaps remain, which ones are being worked on, and which
> ones will be declared "not a gap - won't fix"?
>  >
>  
Sorry, I meant to point to this as well:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests...



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Steven A. Falco]

On 2/1/24 11:46 AM, Neal Gompa wrote:
> >> I'd like to think that the gaps will be fixed, but it
> seems to me that because of policy, some gaps (like apps controlling their own window
> placement) will never be fixed.
> >>
> >
> > That is not necessarily true. For your example about window placement,
> > there is this:
> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests...
> >
> >> Is there a way to see what gaps remain, which ones are being worked on, and which
> ones will be declared "not a gap - won't fix"?
> >>
> >
>  
>  Sorry, I meant to point to this as well:
>  https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests... 
Thanks for the links.  I am hopeful that the issues you are tracking will make it in time
for f40.

	Steve

[Kilian Hanich]

Am 01.02.24 um 17:44 schrieb Neal Gompa:
>  That is not necessarily true. For your example about window
> placement,
>  there is
> this:https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_req...
Am 01.02.24 um 17:46 schrieb Neal Gompa:
>  Sorry, I meant to point to this as well:
>  https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests... 
These two are imo more example which try to prove Falco's point because of:
1. How long this is going on.
2. How many attempts this person made so far.
3. How much some of the maintainers don't want *something* like this (if
you go and read through the thread).

But yeah, I hope we get something at some point which isn't as stupidly
complicated like needing to generate and register transient desktop
files to set dynamic window icons (you can't always know them in advance
if you have a plugin based application; or when multiple windows should
have different ones). I know that there is also a proposal (after
multiple failed tries) in discussion, but there are even more
maintainers who don't want that. (And I am kinda afraid that if it comes
around, it will be a non-flatpak thing, which would be sad considering
that I like Flatpak and immutable distros, so I hope that I could at
least turn that "protection" off).

But well, Let's hope for the best.

Kilian Hanich

[Kevin Kofler]

Roberto Ragusa wrote:

>  On 2/1/24 14:29, Steve Cossette wrote:
>  
> > And yes, that /is/ the whole point: We want to foster the use of Wayland,
> > to increase it's adoption, to force people using it to hit snags along
> > the road and fill tickets so those issues can be fixed.
>  "force people" "hit snag"
>  
>  With this kind of attitude, don't be surprised when people describe Fedora
>  as "the beta test" for Red Hat. 
+1, kinda what I was about to say, except with s/beta/alpha/. :-)

        Kevin Kofler

[Leon Fauster]

Am 01.02.24 um 14:18 schrieb Sérgio Basto:
<snip>

>  The problem is not KDE SIG not support X11, the problem is KDE SIG
> want
>  drop X11 and force user to use wayland . 

Looking from the side I wonder If its the SIG or more the circumstances
that everything is in a forward flow and the SIG is facing it. So, if 
the best time was not two or one year ago, and obviously also not now.
When then? The fact is that there must be a point in time when the 
display server takes an evolution step forward.

Pressure in such transition helps to get forward, so I understand the
SIGs POV. Albeit, from the practical POV there are some issue and 
therefore X11 is still the place to be.

Maybe some elaboration should be done about the current state of X11 vs
Wayland (is it just nvidia?) and a timeframe calculation to have a 
resolution. Maybe it won't look so bad then and a interim solution is
then more acceptable.

--
Leon

[Sérgio Basto]

On Thu, 2024-02-01 at 15:31 +0100, Leon Fauster via devel wrote:
>  Am 01.02.24 um 14:18 schrieb Sérgio Basto:
>  <snip>
>  
>  > The problem is not KDE SIG not support X11, the problem is KDE SIG
>  > want
>  > drop X11 and force user to use wayland .
>  
>  
>  Looking from the side I wonder If its the SIG or more the
>  circumstances
>  that everything is in a forward flow and the SIG is facing it. So, if
>  the best time was not two or one year ago, and obviously also not
>  now.
>  When then? The fact is that there must be a point in time when the 
>  display server takes an evolution step forward.
>  
>  Pressure in such transition helps to get forward, so I understand the
>  SIGs POV. Albeit, from the practical POV there are some issue and 
>  therefore X11 is still the place to be.
>  
>  Maybe some elaboration should be done about the current state of X11
>  vs
>  Wayland (is it just nvidia?) and a timeframe calculation to have a 
>  resolution. Maybe it won't look so bad then and a interim solution is
>  then more acceptable. 

I have an obvious answer is when the authors decide, in this case Xorg,
when Xorg decides that it will stop supporting X11, like happened to
Python2 or PHP5 and 7 or Gnome 

In fact, it is something I've been thinking about, IMHO, downstream
shouldn't decide when software is deprecated or not like KDE and Red
HAt did , it's weird to me [1], although in RHEL we could have the
packages via EPEL, I think, and RHEL 10 is only in a year and a half 


[1]
https://www.reddit.com/r/linux/comments/13c7hfk/red_hat_considers_xorg_de...


>  --
>  Leon
>  
>  
>  
>  
>  
>  
>  --
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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/[e-mail]
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue 
-- 
Sérgio M. B.

[Adam Williamson]

On 2024-02-01 07:40, Sérgio Basto wrote:

>  I have an obvious answer is when the authors decide, in this case
> Xorg,
>  when Xorg decides that it will stop supporting X11, like happened to
>  Python2 or PHP5 and 7 or Gnome
>  
>  In fact, it is something I've been thinking about, IMHO, downstream
>  shouldn't decide when software is deprecated or not like KDE and Red
>  HAt did , it's weird to me [1], although in RHEL we could have the
>  packages via EPEL, I think, and RHEL 10 is only in a year and a half 
A lot of the people involved at different parts of the stack are just 
the same people wearing different hats.

Wayland and X.org are both part of freedesktop. Whatever maintenance is 
still happening on X.org is mostly being done by people who primarily 
work on Wayland. There isn't some kind of holy war going on between The 
Wayland Developers who want to kill X.org, and The X.org Developers who 
believe it is great and want to keep it. They're nearly all the same 
people, and they all want X.org to die. AFAIK there isn't anybody who is 
actually clamoring to *do the work of maintaining X.org upstream*. There 
are people who don't want it to die because Wayland doesn't yet have the 
features they need or the NVIDIA proprietary driver doesn't work well on 
Wayland or whatever, but AFAIK, none of those people is actually 
volunteering to maintain X.org long-term. If you look through 
https://gitlab.freedesktop.org/xorg/xserver/-/commits/master you will 
see the majority of commits are from people who also work on Wayland 
(and most of the commits are actually to Xwayland).

A lot of the same people who are the graphics stack maintainers for 
freedesktop.org are *also* involved in distribution efforts to move to 
Wayland. So it's not as simple as "distributions making the decisions 
instead of upstream". AFAIK, most of the upstream folks dearly *want* 
distributions to move off of X.org and onto Wayland, but they feel kind 
of obliged to continue minimal maintenance of X.org upstream until this 
move is further along.

Apologies if any of that is inaccurate, and I'm sure folks will correct 
me if so.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net

[Peter Hutterer]

On Thu, Feb 01, 2024 at 03:40:24PM +0000, Sérgio Basto wrote:
>  On Thu, 2024-02-01 at 15:31 +0100, Leon Fauster via devel wrote:
>  > Am 01.02.24 um 14:18 schrieb Sérgio Basto:
>  > <snip>
>  > 
>  > > The problem is not KDE SIG not support X11, the problem is KDE SIG
>  > > want
>  > > drop X11 and force user to use wayland .
>  > 
>  > 
>  > Looking from the side I wonder If its the SIG or more the
>  > circumstances
>  > that everything is in a forward flow and the SIG is facing it. So, if
>  > the best time was not two or one year ago, and obviously also not
>  > now.
>  > When then? The fact is that there must be a point in time when the 
>  > display server takes an evolution step forward.
>  > 
>  > Pressure in such transition helps to get forward, so I understand the
>  > SIGs POV. Albeit, from the practical POV there are some issue and 
>  > therefore X11 is still the place to be.
>  > 
>  > Maybe some elaboration should be done about the current state of X11
>  > vs
>  > Wayland (is it just nvidia?) and a timeframe calculation to have a 
>  > resolution. Maybe it won't look so bad then and a interim solution is
>  > then more acceptable.
>  
>  
>  I have an obvious answer is when the authors decide, in this case Xorg,
>  when Xorg decides that it will stop supporting X11, like happened to
>  Python2 or PHP5 and 7 or Gnome  
X.org (the ppl doing X development) doesn't work that way, there won't
be an official "we're no longer supporting this". More likely
development will languish (except for Xwayland) and actual Xorg releases
will be few and far in between, at unpredictable cadence and subject to
someone wanting to do it.

The last Xorg release (21.0) from the master branch was in Oct 2021. The
only reason that one happened was because Povilas (who wanted a new
feature in X) stepped up and did the work of collecting the MRs and
doing the release maintainership. Every 21.x release since has been
backports and, especially more recently, a huge percentage are CVE fixes.

Fedora still ships the previous release, server 1.20.x, which was
originally released from git master in 2018, the 1.20.14 version we're
on (excluding fixes and CVEs) is from Dec 2021.

Xwayland on the other hand (which lives in the same git repo) continues
on its merry way with the 23.2 series branched as recently as last
August. But an Xwayland release does not include Xorg because, well,
there is little motivation to do more Xorg releases. 

When it comes down to it it "just" needs someone (trustworthy enough) to
step up and do them. Whether the releases get picked up immediately like in
the olden days is a different matter. But I doubt there'll be an X.org
statement of "we no longer support Xorg" anytime soon, even though that
is, to some extent functionally already true.

Cheers,
  Peter


> 
> In fact, it is something I've been thinking about, IMHO, downstream
> shouldn't decide when software is deprecated or not like KDE and Red
> HAt did , it's weird to me [1], although in RHEL we could have the
> packages via EPEL, I think, and RHEL 10 is only in a year and a half 
> 
> 
> [1]
>
https://www.reddit.com/r/linux/comments/13c7hfk/red_hat_considers_xorg_de...
> 
> 
> > --
> > Leon
> > 
> > 
> > 
> > 
> > 
> > 
> > --
> > _______________________________________________
> > devel mailing list -- devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> > 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/[e-mail]
> > Do not reply to spam, report it:
> > https://pagure.io/fedora-infrastructure/new_issue
> 
> -- 
> Sérgio M. B.
> --
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> 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/[e-mail]
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Neal Gompa]

On Fri, Feb 2, 2024 at 10:47 AM Peter Hutterer <peter.hutterer(a)who-t.net&gt; wrote:
>  On Thu, Feb 01, 2024 at 03:40:24PM +0000, Sérgio Basto wrote:
>  > On Thu, 2024-02-01 at 15:31 +0100, Leon Fauster via devel wrote:
>  > > Am 01.02.24 um 14:18 schrieb Sérgio Basto:
>  > > <snip>
>  > >
>  > > > The problem is not KDE SIG not support X11, the problem is KDE SIG
>  > > > want
>  > > > drop X11 and force user to use wayland .
>  > >
>  > >
>  > > Looking from the side I wonder If its the SIG or more the
>  > > circumstances
>  > > that everything is in a forward flow and the SIG is facing it. So, if
>  > > the best time was not two or one year ago, and obviously also not
>  > > now.
>  > > When then? The fact is that there must be a point in time when the
>  > > display server takes an evolution step forward.
>  > >
>  > > Pressure in such transition helps to get forward, so I understand the
>  > > SIGs POV. Albeit, from the practical POV there are some issue and
>  > > therefore X11 is still the place to be.
>  > >
>  > > Maybe some elaboration should be done about the current state of X11
>  > > vs
>  > > Wayland (is it just nvidia?) and a timeframe calculation to have a
>  > > resolution. Maybe it won't look so bad then and a interim solution is
>  > > then more acceptable.
>  >
>  >
>  > I have an obvious answer is when the authors decide, in this case Xorg,
>  > when Xorg decides that it will stop supporting X11, like happened to
>  > Python2 or PHP5 and 7 or Gnome
>
>  X.org (the ppl doing X development) doesn't work that way, there won't
>  be an official "we're no longer supporting this". More likely
>  development will languish (except for Xwayland) and actual Xorg releases
>  will be few and far in between, at unpredictable cadence and subject to
>  someone wanting to do it.
>
>  The last Xorg release (21.0) from the master branch was in Oct 2021. The
>  only reason that one happened was because Povilas (who wanted a new
>  feature in X) stepped up and did the work of collecting the MRs and
>  doing the release maintainership. Every 21.x release since has been
>  backports and, especially more recently, a huge percentage are CVE fixes.
>
>  Fedora still ships the previous release, server 1.20.x, which was
>  originally released from git master in 2018, the 1.20.14 version we're
>  on (excluding fixes and CVEs) is from Dec 2021.
>
>  Xwayland on the other hand (which lives in the same git repo) continues
>  on its merry way with the 23.2 series branched as recently as last
>  August. But an Xwayland release does not include Xorg because, well,
>  there is little motivation to do more Xorg releases.
>
>  When it comes down to it it "just" needs someone (trustworthy enough) to
>  step up and do them. Whether the releases get picked up immediately like in
>  the olden days is a different matter. But I doubt there'll be an X.org
>  statement of "we no longer support Xorg" anytime soon, even though that
>  is, to some extent functionally already true.
>  
And even before that, things were already only limping along. That was
happening for over a decade and in that timeframe *nobody* has wanted
to step up and work on it. Wayland is the future because otherwise we
have no graphics future, as things currently stand.

This is why *every* graphical environment is *finally* working on
their Wayland environments if they have any development resources at
all. Last year, we had Cinnamon release its own experimental Wayland
session with v6.0. Budgie is working on replacing X11 with Wayland
this year. LXQt will be on Wayland with v2. Xfce is working on the
same for v4.20. MATE is looking at Wayfire after previously looking at
Mirco for Wayland. Pantheon has been working on it for over a year now
and has an experimental session.

Everyone is making a path to Wayland a priority because finally enough
is done so that they can.



--
真実はいつも一つ！/ Always, there's only one truth!

[Peter Hutterer]

On Fri, Feb 02, 2024 at 11:08:15AM +0000, Neal Gompa wrote:
>  On Fri, Feb 2, 2024 at 10:47 AM Peter Hutterer
> <peter.hutterer(a)who-t.net&gt; wrote:
>  >
>  > On Thu, Feb 01, 2024 at 03:40:24PM +0000, Sérgio Basto wrote:
>  > > On Thu, 2024-02-01 at 15:31 +0100, Leon Fauster via devel wrote:
>  > > > Am 01.02.24 um 14:18 schrieb Sérgio Basto:
>  > > > <snip>
>  > > >
>  > > > > The problem is not KDE SIG not support X11, the problem is KDE SIG
>  > > > > want
>  > > > > drop X11 and force user to use wayland .
>  > > >
>  > > >
>  > > > Looking from the side I wonder If its the SIG or more the
>  > > > circumstances
>  > > > that everything is in a forward flow and the SIG is facing it. So, if
>  > > > the best time was not two or one year ago, and obviously also not
>  > > > now.
>  > > > When then? The fact is that there must be a point in time when the
>  > > > display server takes an evolution step forward.
>  > > >
>  > > > Pressure in such transition helps to get forward, so I understand the
>  > > > SIGs POV. Albeit, from the practical POV there are some issue and
>  > > > therefore X11 is still the place to be.
>  > > >
>  > > > Maybe some elaboration should be done about the current state of X11
>  > > > vs
>  > > > Wayland (is it just nvidia?) and a timeframe calculation to have a
>  > > > resolution. Maybe it won't look so bad then and a interim solution is
>  > > > then more acceptable.
>  > >
>  > >
>  > > I have an obvious answer is when the authors decide, in this case Xorg,
>  > > when Xorg decides that it will stop supporting X11, like happened to
>  > > Python2 or PHP5 and 7 or Gnome
>  >
>  > X.org (the ppl doing X development) doesn't work that way, there won't
>  > be an official "we're no longer supporting this". More likely
>  > development will languish (except for Xwayland) and actual Xorg releases
>  > will be few and far in between, at unpredictable cadence and subject to
>  > someone wanting to do it.
>  >
>  > The last Xorg release (21.0) from the master branch was in Oct 2021. The
>  > only reason that one happened was because Povilas (who wanted a new
>  > feature in X) stepped up and did the work of collecting the MRs and
>  > doing the release maintainership. Every 21.x release since has been
>  > backports and, especially more recently, a huge percentage are CVE fixes.
>  >
>  > Fedora still ships the previous release, server 1.20.x, which was
>  > originally released from git master in 2018, the 1.20.14 version we're
>  > on (excluding fixes and CVEs) is from Dec 2021.
>  >
>  > Xwayland on the other hand (which lives in the same git repo) continues
>  > on its merry way with the 23.2 series branched as recently as last
>  > August. But an Xwayland release does not include Xorg because, well,
>  > there is little motivation to do more Xorg releases.
>  >
>  > When it comes down to it it "just" needs someone (trustworthy enough) to
>  > step up and do them. Whether the releases get picked up immediately like in
>  > the olden days is a different matter. But I doubt there'll be an X.org
>  > statement of "we no longer support Xorg" anytime soon, even though that
>  > is, to some extent functionally already true.
>  >
>  
>  And even before that, things were already only limping along. That was
>  happening for over a decade and in that timeframe *nobody* has wanted
>  to step up and work on it. Wayland is the future because otherwise we
>  have no graphics future, as things currently stand. 
It also doesn't help that the "it's the same people working on X and
Wayland" argument means that, absent significant breakthroughs in
space-time research, we can work on one or the other, not both.
Something's got to give.

Cheers,
  Peter


> 
> This is why *every* graphical environment is *finally* working on
> their Wayland environments if they have any development resources at
> all. Last year, we had Cinnamon release its own experimental Wayland
> session with v6.0. Budgie is working on replacing X11 with Wayland
> this year. LXQt will be on Wayland with v2. Xfce is working on the
> same for v4.20. MATE is looking at Wayfire after previously looking at
> Mirco for Wayland. Pantheon has been working on it for over a year now
> and has an experimental session.
> 
> Everyone is making a path to Wayland a priority because finally enough
> is done so that they can.

[Zbigniew Jędrzejewski-Szmek]

On Mon, Feb 05, 2024 at 10:34:13AM +1000, Peter Hutterer wrote:
>  > And even before that, things were already only limping along.
> That was
>  > happening for over a decade and in that timeframe *nobody* has wanted
>  > to step up and work on it. Wayland is the future because otherwise we
>  > have no graphics future, as things currently stand.
>  
>  It also doesn't help that the "it's the same people working on X and
>  Wayland" argument means that, absent significant breakthroughs in
>  space-time research, we can work on one or the other, not both.
>  Something's got to give. 
We could also switch to a 4-day week, with 20h shifts ;)

Zbyszek

[Peter Hutterer]

On Mon, Feb 05, 2024 at 10:33:52AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
>  On Mon, Feb 05, 2024 at 10:34:13AM +1000, Peter Hutterer wrote:
>  > > And even before that, things were already only limping along. That was
>  > > happening for over a decade and in that timeframe *nobody* has wanted
>  > > to step up and work on it. Wayland is the future because otherwise we
>  > > have no graphics future, as things currently stand.
>  > 
>  > It also doesn't help that the "it's the same people working on X and
>  > Wayland" argument means that, absent significant breakthroughs in
>  > space-time research, we can work on one or the other, not both.
>  > Something's got to give.
>  
>  We could also switch to a 4-day week, with 20h shifts ;) 
"if 24h in a day isn't enough, work at night"

Uncredited because I'm not sure the person I got this from (in jest)
really wants the credit ;)

Cheers,
  Peter

[Chuck Anderson]

On Tue, Feb 06, 2024 at 09:56:30AM +1000, Peter Hutterer wrote:
>  On Mon, Feb 05, 2024 at 10:33:52AM +0000, Zbigniew Jędrzejewski-Szmek
> wrote:
>  > On Mon, Feb 05, 2024 at 10:34:13AM +1000, Peter Hutterer wrote:
>  > > > And even before that, things were already only limping along. That was
>  > > > happening for over a decade and in that timeframe *nobody* has wanted
>  > > > to step up and work on it. Wayland is the future because otherwise we
>  > > > have no graphics future, as things currently stand.
>  > > 
>  > > It also doesn't help that the "it's the same people working on X
> and
>  > > Wayland" argument means that, absent significant breakthroughs in
>  > > space-time research, we can work on one or the other, not both.
>  > > Something's got to give.
>  > 
>  > We could also switch to a 4-day week, with 20h shifts ;)
>  
>  "if 24h in a day isn't enough, work at night"
>  
>  Uncredited because I'm not sure the person I got this from (in jest)
>  really wants the credit ;) 
Just schedule the work for Q5 (the fifth quarter).

[Kevin Kofler]

Peter Hutterer wrote:
>  Fedora still ships the previous release, server 1.20.x 
So should we not upgrade that to the latest upstream release (Xorg 21.0)?

        Kevin Kofler

[Sérgio Basto]

On Fri, 2024-02-02 at 14:42 +0100, Kevin Kofler via devel wrote:
>  Peter Hutterer wrote:
>  > Fedora still ships the previous release, server 1.20.x
>  
>  So should we not upgrade that to the latest upstream release (Xorg
>  21.0)? 

I'm working on one pull request 
 
https://src.fedoraproject.org/fork/sergiomb/rpms/xorg-x11-server/c/ac2a6d...

builds still fails here: 
+ cp hw/dmx/doxygen/doxygen.conf.in /builddir/build/BUILDROOT/xorg-x11-
server-21.1.11-1.fc38.x86_64//usr/share/xorg-x11-server-
source/hw/dmx/doxygen/doxygen.conf.in
cp: cannot stat 'hw/dmx/doxygen/doxygen.conf.in': No such file or
directory



https://bugzilla.redhat.com/show_bug.cgi?id=1949144


>          Kevin Kofler
>  --
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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/[e-mail]
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue 
-- 
Sérgio M. B.

[Adam Williamson]

On 2024-02-01 04:08, Steve Cossette wrote:
>  So, if you all don't mind, I'd like to steer this discussion
> in a 
>  slightly different way:
>  
>  What /is/ the definition of a Fedora Change Proposal?
>  
>  I was under the impression it was an announcement of intent by the 
>  maintainers of a specific subset of the fedora project to "change" 
>  something. Once said announcement has been discussed publicly, Fesco 
>  (Sorry if the capitals are incorrect) discusses it internally (albeit, 
>  publicly) and either blocks or approves the change, making it official.
>  
>  /(Please note: The following paragraphs will use "we" as a pronoun which 
>  is intended to be the Fedora project as a whole)/
>  /
>  /
>  Once approved, we announced our intent to drop X11 from the KDE spin of 
>  Fedora. That announcement has gained traction everywhere, got publicized 
>  and everything. As Neal Gompa also stated, it has already caused some 
>  substantial development effort upstream to effectively iron out the 
>  rough edges of many of the problems, with what I assume is more to come.
>  I would not read it quite like that. I would say that by approving the  
Change,
"we" - in the sense of "Fedora as a whole" - approved of the KDE 
SIG's decision to stop maintaining Plasma X11. I can't speak for FESCo, 
but if I had been on FESCo, I don't think I would've had in my mind 
"approving this Change creates a ban on anybody at all maintaining 
Plasma X11 packages in Fedora" when voting on it.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net

[Kevin Kofler]

Steve Cossette wrote:
>  It would also introduce a precedent: What if later a proposal is made
> to
>  remove some old drivers from, let's say, the kernel, and someone decides
>  to package it, undermining the general efforts of that proposal? 
The kernel is actually a special case in that there is a specific rule 
banning kernel modules and custom kernels from Fedora. That is a rule 
specifically for the kernel and does not apply to any other package (e.g., 
browser extensions, LibreOffice plugins, Plasma widgets (plasmoids), etc. 
can all be separately packaged).

There have been plugin-based applications where some plugins were dropped 
from the upstream tarball and/or the Fedora packaging, and subsequently 
submitted as separate packages in Fedora. As I understand it, this has never 
been vetoed (for anything other than kernel modules).

The special case for the kernel is something that I am also unhappy with, 
but that is a separate discussion. But I would be really unhappy if this 
became the standard also for userspace.

>  Hopefully I'm making sense. Writing this 30mins after waking up
> might not
>  have helped. What I'm trying to say basically is, I get that for some
>  legacy nvidia users the Wayland experience may not be optimal. But will it
>  *ever* be? Does that mean we can never drop x11? Will anyone ever update
>  those legacy nvidia drivers? *Could they be?* 
Actually, I could not care less about the experience with proprietary NVidia 
drivers. I do not use or intend to use them. That is not the reason I use 
X11. Of course, NVidia users are free to use my packages just like everybody 
else, but as always, I cannot fix bugs in the proprietary driver code, so 
please do not expect me to do miracles there. If X11 works better for NVidia 
users than Wayland, great, but if not, I am afraid there is probably not 
much I can do about that.

        Kevin Kofler

[Kevin Kofler]

I have just found another essential feature that is missing in Plasma 
Wayland: Under X11, I can scale outputs (at X11 level) ignoring the aspect 
ratio. This is essential to unify outputs with different aspect ratios. 
E.g., my notebook has a 1280×800 (8:5/16:10) display. Using xrandr --scale-
from, I can stretch this to 16:9, or even to 1024×768 4:3 which is then 
stretched to 16:9 by the TV. So I see the same thing on the notebook's 
built-in screen and on the TV, slightly distorted, but workable.

Today, I tried to do this trick with my PinePhone (using the convergence 
dock and HDMI output). Plasma Mobile forces Wayland on me. So I look at the 
options of kscreen-doctor, which is purportedly the replacement of xrandr, 
and well, that dumb thing can only apply one scale factor, not different 
ones for horizontal and vertical. So I cannot get truly unified outputs, 
meaning the experience completely sucks. (One or the other display ends up 
truncated and impossible to work with. Also because Plasma insists on 
filling the larger display and truncating the smaller one instead of filling 
the smaller one and letterboxing the larger one as it should.) So this means 
1. Wayland will never be suitable for my notebook, and 2. one of these days 
I am going to have to port Plasma Mobile to X11.

        Kevin Kofler

[Neal Gompa]

On Tue, Feb 20, 2024 at 9:55 AM Kevin Kofler via devel
<devel(a)lists.fedoraproject.org&gt; wrote:
>  I have just found another essential feature that is missing in Plasma
>  Wayland: Under X11, I can scale outputs (at X11 level) ignoring the aspect
>  ratio. This is essential to unify outputs with different aspect ratios.
>  E.g., my notebook has a 1280×800 (8:5/16:10) display. Using xrandr --scale-
>  from, I can stretch this to 16:9, or even to 1024×768 4:3 which is then
>  stretched to 16:9 by the TV. So I see the same thing on the notebook's
>  built-in screen and on the TV, slightly distorted, but workable.
>
>  Today, I tried to do this trick with my PinePhone (using the convergence
>  dock and HDMI output). Plasma Mobile forces Wayland on me. So I look at the
>  options of kscreen-doctor, which is purportedly the replacement of xrandr,
>  and well, that dumb thing can only apply one scale factor, not different
>  ones for horizontal and vertical. So I cannot get truly unified outputs,
>  meaning the experience completely sucks. (One or the other display ends up
>  truncated and impossible to work with. Also because Plasma insists on
>  filling the larger display and truncating the smaller one instead of filling
>  the smaller one and letterboxing the larger one as it should.) So this means
>  1. Wayland will never be suitable for my notebook, and 2. one of these days
>  I am going to have to port Plasma Mobile to X11.
>  
Or 3. you could go ask for the feature to be exposed, because in
Wayland, we have more flexibility on how outputs are managed at all.


-- 
真実はいつも一つ！/ Always, there's only one truth!

[Kevin Kofler]

Neal Gompa wrote:
>  Or 3. you could go ask for the feature to be exposed, because in
>  Wayland, we have more flexibility on how outputs are managed at all. 
Well, Plasma has had decades to get multiple outputs and scaling working. It 
has always been a lost cause. (At least for the one configuration I care 
about, which is mirrored displays stretched to display identical contents no 
matter the aspect ratio, for presentations and meetings.) The introduction 
of the XRandR X11 extension has been a godsend. Ever since, the one way to 
get things working has always been to talk to XRandR directly over the CLI 
and bypass Plasma entirely. Even fractional scaling on X11 is a non-issue if 
you just let X11 do the scaling, so that neither Plasma nor the applications 
even realize that their display is being scaled, let alone that it is being 
fractionally scaled with a different fraction horizontally and vertically. 
They just see a framebuffer of the size they want, and everything is scaled 
by X11/XRandR behind their back. So it just works. (Yes, it is blurry and/or 
some pixels are lost. But it does not look that bad in practice.) 
Unfortunately, this is not an option in Wayland because there is no X server 
that can do the scaling behind Plasma's back under Wayland.

        Kevin Kofler

[Neal Gompa]

On Tue, Feb 20, 2024 at 11:32 AM Kevin Kofler via devel
<devel(a)lists.fedoraproject.org&gt; wrote:
>  Neal Gompa wrote:
>  > Or 3. you could go ask for the feature to be exposed, because in
>  > Wayland, we have more flexibility on how outputs are managed at all.
>
>  Well, Plasma has had decades to get multiple outputs and scaling working. It
>  has always been a lost cause. (At least for the one configuration I care
>  about, which is mirrored displays stretched to display identical contents no
>  matter the aspect ratio, for presentations and meetings.) The introduction
>  of the XRandR X11 extension has been a godsend. Ever since, the one way to
>  get things working has always been to talk to XRandR directly over the CLI
>  and bypass Plasma entirely. Even fractional scaling on X11 is a non-issue if
>  you just let X11 do the scaling, so that neither Plasma nor the applications
>  even realize that their display is being scaled, let alone that it is being
>  fractionally scaled with a different fraction horizontally and vertically.
>  They just see a framebuffer of the size they want, and everything is scaled
>  by X11/XRandR behind their back. So it just works. (Yes, it is blurry and/or
>  some pixels are lost. But it does not look that bad in practice.)
>  Unfortunately, this is not an option in Wayland because there is no X server
>  that can do the scaling behind Plasma's back under Wayland.
>  
Have you considered that perhaps the reason it wasn't possible before
was *because* of the X server?

I do think plenty of people would disagree with your statement about
how good it looks when you warp the display like you propose, but not
even bothering to ask for the feature at all guarantees that it won't
exist.

I know you're capable of filing requests for features on the KDE bug
tracker, so if this is something you believe you need, then you should
request it.

If you won't even bother with that much, I don't think I or anyone
else can take you seriously when it comes to your criticism of Plasma
Wayland, especially since upstream KDE is oriented around it and has
been for many years now.




--
真実はいつも一つ！/ Always, there's only one truth!

[Kevin Kofler]

Neal Gompa wrote:
>  I know you're capable of filing requests for features on the KDE
> bug
>  tracker, so if this is something you believe you need, then you should
>  request it. 
https://bugs.kde.org/show_bug.cgi?id=481584

(In case you wonder, I set the platform to "Manjaro" because that is what my 
PinePhone currently runs. In the end, the distribution should not matter 
anyway, this is clearly an upstream Plasma issue.)

        Kevin Kofler

[Solomon Peachy]

On Tue, Feb 20, 2024 at 03:54:54PM +0100, Kevin Kofler via devel wrote:
>  the smaller one and letterboxing the larger one as it should.) So
> this means 
>  1. Wayland will never be suitable for my notebook, and 2. one of these days 
>  I am going to have to port Plasma Mobile to X11. 
Or, uh, (3) Port/add this functionality to Plasma/Wayland?

(There's nothing in Wayland that precludes this from working; just 
 nobody's bothered to implement it)

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
Dowling Park, FL                      speachy (libera.chat)

[Jonathan Wakely]

On Tue, 20 Feb 2024 at 14:55, Kevin Kofler via devel
<devel(a)lists.fedoraproject.org&gt; wrote:
>  I have just found another essential feature that is missing in Plasma
>  Wayland: 
The big one for me is that Synergy and similar tools barrier and
input-leap don't work under Wayland. I don't see that mentioned at
https://community.kde.org/Plasma/Wayland_Known_Significant_Issues

My understanding is that it's now possible using libEI, but only Gnome
makes use of that. Support for KDE is tracked by
https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/issues/12 but
doesn't look close to being ready.

[Neal Gompa]

On Tue, Mar 19, 2024 at 6:49 AM Jonathan Wakely
<jwakely(a)fedoraproject.org&gt; wrote:
>  On Tue, 20 Feb 2024 at 14:55, Kevin Kofler via devel
>  <devel(a)lists.fedoraproject.org&gt; wrote:
>  >
>  > I have just found another essential feature that is missing in Plasma
>  > Wayland:
>
>  The big one for me is that Synergy and similar tools barrier and
>  input-leap don't work under Wayland. I don't see that mentioned at
>  https://community.kde.org/Plasma/Wayland_Known_Significant_Issues
>
>  My understanding is that it's now possible using libEI, but only Gnome
>  makes use of that. Support for KDE is tracked by
>  https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/issues/12 but
>  doesn't look close to being ready. 
It is targeted for Plasma 6.1, with the first step written for kwin:
https://invent.kde.org/plasma/kwin/-/merge_requests/5412



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Kevin Kofler]

Neal Gompa wrote:
>  It [libEI(S) support] is targeted for Plasma 6.1, with the first
> step
>  written for kwin:
>  https://invent.kde.org/plasma/kwin/-/merge_requests/5412 
For some definition of "written". This is still in draft state, and in 
particular still missing authentication and filtering, so it completely 
defeats the Wayland security architecture (anybody can capture all input, 
just as on X11), which means it will definitely not be merged in this state.

        Kevin Kofler