Wayland-Protocols 1.19 Released With Governance Guide, Updated XDG-Shell

[ssokolow]

I find this discussion very amusing, given that "meritocracy" was coined with the intent to be a bad thing.

https://en.wikipedia.org/wiki/The_Rise_of_the_Meritocracy

[Gusar]

tildearrow Yeah, this is beyond hilarious. Just look at this thread. It goes like this:

144hz: mentions meritocracy
tildearrow: brings up Outreachy
144hz: doesn't get it
also 144hz: "no affirmative action allowed"

I mean, you can't make this stuff up! This is just gold! And to top it off, 144hz then also speaks about "the Meritocracy"! And note, it's not me adding the capitalization here, that's exactly what 144hz wrote - "the Meritocracy". WTF, I'm dying of laughter here...

[tildearrow]

144Hz Oh wow, that is some nonsense right there.... Your interpretation of "meritocracy" is the inverse...

[Gusar]

LOL @ "the Meritocracy"

[CuriousTommy]

Would the repositioning of pop-up help with the wine-wayland issue?

[Gusar]

What do you expect? Wayland devs are under no obligation to bend backwards to accommodate some random dude's obscure compositor written as a hobby project. If you desperately need some additional features for your non-GNOME desktop, the onus is on you to 1. implement them and 2. convince the upstream devs that it's really, really worth it to pollute their codebase by merging them in. And if you can't convince them, it's up to you to fork Wayland and hope that it will fly. That's how FOSS has always worked.

Kwin and wlroots are not "some random dude's obscure compositors". They did implement stuff themselves, and said stuff did make it upstream - xdg-decoration and idle-inhibit are in wayland-protocols. But there is a problem, in that the two protocols I just mentioned aren't a requirement but are merely "optional". Making wayland-protocols effectively meaningless.

Advocating forks on the window-system level is beyond silly. Such fragmentation doesn't help anyone, it doesn't help application developers - who need to have environment-specific code in their app for each environment they intend to support or limit their app to a single environment, and it doesn't help users - who have a limited number of applications to choose from and can't mix and match applications from different environments.

Diversity at the application level is good. But the underlying plumbing needs to be unified to allow interoperability. This exists in the X world thanks to standards like EWMH. This *could* exist in the Wayland world in the form of wayland-protocols, but it doesn't work in practice when protocols necessary for interoperability are "optional".

Canoncal was blasted into oblivion for creating Mir instead of making Unity a Wayland compositor. Rightfully so. But here you are, advocating for the same scenario - fragmentation at the windowing-system level.

[jacob]

What meritocracy?! Then why does the Code of Conduct and Outreachy exist?

What if an Outreachy psychiatric patient decides to "identify" as having merit? It's up to GNOME to rise up to zer/xih Lived Experience(tm).

[jacob]

144Hz Can you even show me proof of meritocracy on GNOME nowadays?

(plus why are we talking about GNOME? get back on topic, this is about Wayland in general)

Wayland "in general" means mainly GNOME, with KDE as a distant second, and a bunch of more or less experimental projects that hardly anyone uses outside of niche applications (Sway etc.)

[tildearrow]

144Hz Can you even show me proof of meritocracy on GNOME nowadays?

(plus why are we talking about GNOME? get back on topic, this is about Wayland in general)

[tildearrow]

What meritocracy?! Then why does the Code of Conduct and Outreachy exist?

144Hz seriously you disturb me to no end!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!