cc @mia Maybe this could of interest to you. I do remember to see you posting about wayland-stuff here and there

ps: I did make this post as answer before. But thought that maybe quoting is the better sorry mia for the double mention.

RE: https://idtech.space/objects/f5221e5a-b025-4aaf-ba92-4563f21f2046

@emersion @frog I wrote up a slightly longer post that came out kind of annoyed, so I wanted to reword this: can you please like, suggest what you actually would like to see? Because this isn't actionable. This just greatly complicates the situation and I don't think this helps anywhere as much as you think it does.

@Lyude @emersion the governance model is totally broken, and needs to be just removed and should be replaced with controlled anarchy like Mesa.

the fact that the repository is anything more than a collection of XML files that compositors and clients handshake on is a huge mistake. w-p should not be set up like a standards body. it doesn't deal with ip or legal frameworks like Khronos does; and the current w-p governance represents but a tiny selection of clients and compositors.

whenever something new is proposed, the immediate reaction is typically "this goes against my ideology for what i think is pure and right for Wayland," which is totally messed up and not conducive to actually fixing any problems. take the window icons protocol, 95% of that whole thing was just utterly useless noise and what-about-ism.

it is not just a "technical" problem, the way people treat others with differing opinions and schools of thought about how something should or could be done is really bad, and even if certain people are not directly members, they are associated/affiliated to projects who are, and act incredibly hostile.

in my experience, wayland-protocols is just a lot of power-tripping and useless arguing, and not much actually solving problems.

as mentioned by me and others, the bar for entry for a protocol to land even in 'staging' is ludicrously high, which leads to features taking literally half a decade to land at some times.

having a path for experimental protocols in w-p -- ie. something that can be rapidly iterated on and implemented by clients and compositors, and shipped to users is a total must.

experimental protocols can follow the basic iteration groundrules of what I defined in frog-protocols to avoid there being an immense amount of churn there.

but I think all of this is incompatible with the current governance model.

@frog thank you for writing this up! Honestly I completely agree with you, and it's almost kind of weird that this is what has been happening with w-p at least from my perspective of having worked on it a number of years ago. Previously when I worked on the drawing tablet protocol as a GSoC student it was really emphasized to me that it's difficult to simply write a perfect protocol, you need to be able to actually test it out in the real world to see what needs to be changed

@frog it makes me think that this has sort of also stemmed from the issues we had getting protocols into core Wayland, because the overarching opinion was that the core Wayland protocol should remain as small as possible - which was one of the reasons w-p was started in the first place. It feels like now though w-p isn't being treated as staging anymore because of how many protocols are actually in there, which itself is a problem because yeah - this stuff needs to get shipped to perfect it

@frog also FWIW I didn't assume this would be a "technical" problem. Honestly I kind of hate that term. Open source communities have their own politics and it's kind of naive to pretend that those politics don't directly affect actual development - the reality is they're just as much of a "technical issue" as actual code is.

@Lyude @frog I think people like to pretend that it's possible to be "just about the tech", but technology is aimed to serve people and solve their problems, so naturally the relationships among the folks working on the tech matter just as much, if not more so.

@Conan_Kudo @frog I will say though - I still don't think we can treat stuff like frogs as a permanent solution. it would be really helpful if y'all would at least put something along the lines (maybe you have already, I'll admit I haven't checked) of these protocols not being finalized.
I've actually been seeing a lot of good conversation with people today about how we could make the bars for getting protocols into w-p less of an issue. but basically everyone, myself included, is incredibly worried about the possibility of another repository like this just sort of side-stepping actual consensus from communities.

@Lyude @Conan_Kudo i would argue that consensus is already sidestepped in much worse way by virtue of the majority of the wider community being not being represented by the current governance situation in any way.

@Conan_Kudo @frog It would both help to actually push other projects to consider using these protocols, and come across in good faith to communities. Because I have to be honest, I completely understand why people are upset by this. If we just pushed every single protocol into the hands of users immediately without a second thought we will be stuck with literally ever decision we ever make until we have to fork something and start over.
It's really tempting to look at actual working PoC implementations we have and say to ourselves "well sure, that can't happen". But that's like, literally exactly 100% how this always starts. we can't just put off trying to fix things as being impossible.

@Conan_Kudo @Lyude @frog over the year's I've come to realize that "It's just about the tech" is a dog whistle for shitty behavior that people don't want to change. I've but up with so much BS because of that.

@frog @Conan_Kudo So how does forking and adding two different protocol repositories actually fix this issue outside of the compositors currently using one or the other? How do you know that not only the compositors participating in this repository will actually get a say in these protocols when actual software is going to rely on them? Are you going to be open to projects like GNOME and sway actually contributing? what are the actual genuine plans for pushing any of this back upstream?

@Lyude @Conan_Kudo anyone can contribute to this repository, but i obviously cannot force them -- if they do not wish to participate in the project and ship protocols from this repo, that is their choice.

pretty much everything else is an unknown and a bridge to cross someday if this project continues.

one of the big problems with wayland stuff is putting the cart before the horse, and i have no intention of doing that right now. i don't plan much in my life :-)

@frog @Conan_Kudo And if wayland-protocols does get its shit together, what then?

@Lyude @Conan_Kudo the project will have been a success

@Lyude @Conan_Kudo @frog and the even scarier problem is that "a multitude of rushed and incompatible protocols" is one of the reasons X turned so messy and broken but couldn't be fundamentally fixed (according to my understanding of people that were there explaining it, i might be wrong)

My hot take here is that... just because you shipped it earlier doesn't mean that much for its quality.

Some kind of early testing of protocols is useful but it would require some tight integration of the stack so that deprecation definitely happens. So for example proton using gamescope-specific protols, or a similar thing on KDE and GTK.

@ada_magicat @Lyude @Conan_Kudo the good thing about Wayland is you can just not support any protocol, and protocols are entirely 'decentralized' which avoids this in the long term.

@frog @emersion @Lyude I think it's important to note that this is partly why we see all the incompatible approaches to integration done by the different desktops.

GNOME uses a couple of private protocols, but mostly D-Bus interfaces. KDE uses a pile of private protocols and third-party protocols, and most of the other desktops are following similar approaches.

The brand new COSMIC desktop is doing something similar, and I think that illustrates the point that something needs to change here.

@frog @emersion @Lyude To make my point clearer: we already have fragmentation and incoherence for Wayland integration because the central integration effort appears to be too hard for most desktop and application developers to want to do it.

@Conan_Kudo @frog @emersion @Lyude I'm actually not really aware of the purpose of these private protocols (especially the dbus ones). Do you have some examples on hand and why they are even needed?

@ada_magicat @Conan_Kudo @emersion @Lyude eg. gamescope uses this protocol to talk to it's layer: https://github.com/ValveSoftware/gamescope/blob/master/protocol/gamescope-swapchain.xml

@pq @frog @emersion

Please just please get screen readers working. I have a friend that is completely blind. Wayland is not an option right now.

I also don’t see this getting fixed within the next 3 to 6 years that means Linux off the table for these users. Since I highly doubt distributions will inform users that when they are going to drop X11 that they will. 

@ada_magicat @Lyude @Conan_Kudo @frog people really really really overestimate how bad fragmentation caused by making the wrong thing is. It's understandable as a platform developer to be worried about long term maintenance, but it's really a problem that is entirely constricted to that area. As a consumer of these APIs fragmentation can be annoying, but building something out of multiple extensions already fundamentally fragments things, so +- some for an extra protocol is a small worry.

@ada_magicat @Lyude @Conan_Kudo @frog far more of an issue is when you try to figure out how to implement something and there's 3 in-progress protocols which have all stalled for multiple years and contain 300+ messages of aimless arguments about nothing. That is far worse than needing to do a v2 of a protocol, or needing to deprecate some protocol and have compositors support it long term.

@serebit @frog We've already been experimenting new protocols in w-p with the xx prefix (with the color management protocol for instance)

@emersion @serebit would you have objection to those being merged into Mesa?

@frog Everybody can suggest improvements. Everybody can apply to be an "insider". All "insiders" are reasonable people and will listen to you if you throw ideas around.

But really, I don't think there is a high barrier between "insiders" and "outsiders". Many "outsiders" are super active in w-p and have a high impact.

@emersion if Gamescope applied to be a member, do you believe it would be NACK'ed? (genuine question)

@frog Replacing a formal governance designed to give everybody a voice and avoid gatekeeping (yes, that's why the governance exists in the first place), with the wild west without clear rules of who can do what when, is a regression in my eyes. Not saying w-p is perfect in any means.

@emersion

From an outsider's perspective watching some of those protocols being proposed and discussed - it seems like the biggest problem is how easy it is to stall all the work.

It feels like there's a pattern of "sharing concerns" that the original author doesn't agree with, often by a non-member. This acts almost as a NACK without being an official one. It's hard to move past that point as "someone is unhappy". Especially when most of the members don't really have an option and don't push for inclusion of those protocols.

FWIW I really appreciate that folks been actively reminding people that they don't have NACK powers and they should stop acting as such, but that doesn't fully solve the problem.

Looking at the governance document:

1.1.2 Members represent general-purpose projects with a stake in multiple Wayland protocols (e.g. compositors, GUI toolkits, etc), rather than special-purpose applications with a stake in only one or two.

This makes it sound like a lot of projects don't qualify. I would assume that gamescope is too narrow to be included. Mesa as well. If that's not the case rewording it would be great.

I would love to see some gaming / 3D representation with the likes of mesa, gamescope, and maybe, in a distant future, winewayland.drv.

With that it would be possible to get some of the game- / presentation-oriented protocols into ext- quicker as you have more invested parties.

1.2.1 New members who meet the criteria outlined in 1.1 are established by invitation from an existing member. Projects hoping to join should reach out to an existing member asking for this invitation.

Maybe inviting projects in a more proactive way would help with the outsider vs insider issue? If you see people working on protocols for a known project extending an invitation would be nice.

@ivyl @emersion I think that first requirement, as stated, would apply to any compositor (or GUI toolkit), which pretty fundamentally has an interest in more than a couple protocols. At least.

I guess it does exclude things like input method engines and accessibility tools, which may be only interested in a protocol or two. (Getting those kinds of projects more involved in Wayland and getting the necessary protocols right and implemented is another major issue with Wayland currently.)

@emersion @frog you mean all insiders are reasonable people, including the one who tried to get me fired from my job... (which thankfully, wasn't even my job) Yeah, it's a great and welcoming community to be sure.

@emersion @frog But more related to the topic at hand, I think this exact kind of "no that's actually not a problem" response to people talking about issues they have, is a pretty common theme with w-p. It's also the case when you read through responses to some of the MR's and issues, including in comments from insiders (by whatever definition you use). Disagreement is expected to a degree, but the condescension isn't necessary.

@emersion @frog In my own personal experience, I really lost all hope when I saw people being condescending and generally just rude to icculus, of all people, on w-p. If their contributions don't allow them the benefit of even vague politeness when their input is dismissed out-of-hand I don't know what hope anybody else has.

@serebit @frog And packaged on Solus now as well: https://github.com/getsolus/packages/tree/main/packages/f/frog-protocols

@frog@idtech.space i like frogs 🐸