wayland-protocols scope and governance

[Drew DeVault]

This is a great plan, Daniel, thank you for taking the time to write it
up and help push this problem towards a solution.

On 2019-02-19  4:50 PM, Daniel Stone wrote:
> My first, hopefully uncontroversial, suggestion: introduce a list of
> compositors / compositor frameworks, as well as clients / client
> frameworks, and which protocols they use and support. This would help
> both application and compositor authors figure out where they should
> invest time and effort. I suggest that we keep this lightweight: have
> a registry of compositors / compositor frameworks / toolkits /
> clients, each with a couple of named people who can speak
> authoritatively for that project.
> 
> As a strawman list of projects to begin with (I'm sure there are others):
>   - compositors and compositor frameworks: Chromium (Exosphere),
> Enlightenment, KWin, Mutter, Smithay, Sway, Weston/libweston, wlroots

Sway & wlroots probably shouldn't be separate, but it might be useful to
link to the list of wlroots-based projects from the compatability page:

https://github.com/swaywm/wlroots/wiki/Projects-which-use-wlroots

These projects rarely, if ever, implement protocols themselves, opting
instead to implement them in wlroots and share the functionality with
everyone else.

>   - toolkits: EFL, GTK, Qt

GLFW, SDL

>   - media: GStreamer, Kodi, VLC, XBMC

mpv

>   - other clients: Chromium (client), Firefox, Mesa (EGL/Vulkan)

This might start getting out of hand, I think. Here's an incomplete list
of clients which use wlr protocols:

- mako
- slurp
- grim
- wl-stream
- xdg-desktop-portal-wlr
- swaylock
- swayidle
- swaybg (soon)
- waybar
- jaybar
- phosh
- virtboard
- bemenu

This is just the clients I can think of off the top of my head. Consider
also demo clients, like weston and wlroots clients. There's going to be
a lot of clients! Something I want to avoid is making the criteria for
inclusion in the list subjective, and if we have to decide what makes
GLFW worth including and weston-simple-egl worth excluding, I fear
politics will ensue.

> My second suggestion is to formalise the 'xdg' namespace. xdg
> extensions have been accepted or rejected by rough consensus between
> Enlightenment/EFL, GNOME, and KDE. That still seems reasonable enough
> to me, assuming that 'xdg' retains the focus of an integrated (as
> opposed to build-it-yourself) desktop.

What is the criteria for having a voice in this xdg namespace
"consensus"? This seems a bit opinionated and subjective.

> Or Weston hasn't implemented xdg_foreign and probably won't, but I'm
> fine with it existing and being a common extension. On the other hand,
> Weston/Mutter/etc would have very strong opposition to a 'wp_randr'
> extension, and last I saw wlroots would have very strong opposition to
> wp_pointer_gestures. So those wouldn't be wp.

This makes me wonder: what's the role of Weston in this? As a reference
compositor which isn't designed for end-users, I don't think Weston has
ever been well-positioned to be an influencer on Wayland, but should
rather be a reflection of what Wayland is without its influence. Do you
have any thougths on this?

In other words, if Weston doesn't want to implement $protocol: so what?
How do/should the gatekeepers of Weston make these decisions?

> Bikeshedding the prefix to use [for vetoed but still relevant
> protocols] would be welcome, as I don't have any good suggestions
> right now.

xdg?

I think gatekeeping the xdg namespace is going to allow a lot of the
frustrating politics to thrive even with these changes, and it is a nice
namespace for defining these standards.

> Once we've established and codified these ground rules - with a
> document along the lines of Wayland's CONTRIBUTING.md - we can open up
> commit access to wayland-protocols, so we're not so reliant on a
> couple of arbitrary gatekeepers. Obviously this would be done with the
> expectation that those ground rules are followed - don't post a wp_
> extension on a Sunday morning and then commit it in the evening with a
> couple of +1s because no-one objected - but we're all reasonable
> adults, and can treat each other reasonably without having to enforce
> ACLs.
> 
> Does anyone have any thoughts or suggestions here? Is this a good
> aspiration? Is it the best way of achieving that aspiration?

+1

I don't see commit access as a magic equalizer, fwiw. I don't mind
sending a patch along and letting someone else integrate it so long as
they're following well-defined policies and not operating under their
own agenda.

Another thing I'd like to clarify is the process of agreeing on the
appropriate prefix for a protocol. Perhaps there's an experimental_ or
draft_ namespace which has a near-zero barrier to entry (just add your
implementation to the list), and then you can separately make your case
for adopting it into another namespace. During the draft step you can
pitch your protocol to interested parties, write implementations, and so
on, which strengthens the case for including it in some namespace.

Under this process, the xdg and wp and whatever else namespaces reflect
reality, and each protocol there is known to have the support of at
least a few implementations - rather than reflecting that at some point
some number of people agreed it would be a good idea, and then maybe or
maybe didn't write implementations.