wayland-protocols scope and governance

Thu Feb 21 14:00:54 UTC 2019

On Tue, 19 Feb 2019 16:50:27 +0000
Daniel Stone <daniel at fooishbar.org> wrote:

> Hi all,
> I'd like to open up a discussion on enlarging wayland-protocols to a
> wider audience, with a better definition of what it contains.
> 
> Currently, wayland-protocols is a relatively small set of protocols
> which were either grandfathered in from Weston, or a semi-opinionated
> set of protocols that someone thinks is 'good'.
> 
> The original intent was to provide a set of 'blessed' desktop
> protocols which 'everyone' would probably implement in order to
> provide a coherent Wayland environment. To some extent - xdg-shell,
> dmabuf, xdg-output, viewporter - this succeeded. For some others, it
> failed badly - the input protocols no-one likes or has implemented,
> necessitating Dorota's rewrite.
> 
> The elephant in the room is extensions like layer-shell and some of
> the related extensions to build a desktop environment from a set of
> disparate clients using generic APIs. Personally I think the
> experience of X11 shows it's only designing for pain, and this is the
> general position of wayland-protocols at the moment. But on the other
> hand, those protocols aren't going away, they are in use, and having
> them developed in a separate siloed community is doing us all a
> disservice, since neither hand fully knows what the other is doing.
> Even if we don't agree on the fundamentals of the protocol, we could
> at least discuss it and try to point out some pitfalls and make some
> suggestions for improvement.
> 
> A related issue is that it's hard for both application and compositor
> authors to figure out what to do. There is no good 'big picture' on
> how these protocols fit together, nor can people figure out which of
> the competing proposals they should be using if they want to write an
> application running on a given compositor, nor can compositor authors
> figure out what apps want them to support. Depending on who happens to
> be paying attention to the particular forum the question is asked,
> they might get very different answers, depending on the point of view
> of who answers.
> 
> 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.
> 
> We could then allow each project to declare its support (or otherwise)
> for any extension: will not ever implement, implementation not
> planned, no opinion or N/A, implementation planned, implemented but
> use not recommended (or limited/stubbed), implemented and recommended.
> This list would be machine-parseable (XML, JSON, YAML, whatever is
> easiest to fit), with a GitLab CI pipeline used to generate a
> https://wayland.freedesktop.org/protocols/ website on every push,
> which gave both a per-extension and a per-project support table. And
> some more readable docs. I think this would be a really good entry
> point and clear up a lot of confusion.
> 
> 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
>   - toolkits: EFL, GTK, Qt
>   - media: GStreamer, Kodi, VLC, XBMC
>   - other clients: Chromium (client), Firefox, Mesa (EGL/Vulkan)

Hi Daniel,

I wholeheartedly agree on the problem statement and the first
suggestion.

It is as important if not even more to list which software components
have rejected a certain Wayland extension than it is to list which
extensions are supported.

> 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. The IVI namespace would
> similarly be delegated to automotive people, and maybe we could
> delegate the layer_ namespace to those developers as well.
> 
> My third suggestion is to formalise the 'wp' namespace, as core
> extensions that everyone can agree on. It doesn't mean everyone needs
> to implement them, but at least not have active opposition. For
> example, Mutter hadn't implemented wp_viewporter for the longest time,
> but also had no opposition to it being implemented - which wouldn't
> block it being a 'wp' protocol. 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.
> 
> So where does that leave other extensions? My fourth suggestion is
> that we look to the OpenGL/EGL/Vulkan registries: if an extension has
> been vetoed from the wp_ namespace, but still had support and
> implementations from multiple projects, that we still accept and
> publish it under a different namespace which makes it clear that some
> projects think the extension is fundamentally a bad idea, but it is
> also not a compositor-specific extension. Bikeshedding the prefix to
> use here would be welcome, as I don't have any good suggestions right
> now.

Do we actually need these politically differentiated prefixes? Wouldn't
they have exactly the same problems as we have now between various
extension repositories? You outlined some ways to make the decision on
where each extension would belong, but I think that could still cause
friction and delays in getting extensions merged.

Here is a counter-proposal:

Let's forget about the prefixes or namespaces indicating anything about
endorsement or acceptance.

Instead, we have the records (the first suggestion) of which software
projects use/implement/want, are ambivalent or unknown, or refuse each
Wayland extension. Leave it to the reader to decide whether an
extension is worth using, rather than even attempting to convey any
level of blessedness.

If an extension is explicitly refused by gnome-shell but implemented by
wlroots, I think that would speak loud and clear on how portable that
is.

The benefit is that we avoid almost all of the design-political
debates. The only policy question left to answer is what kind of
extensions are eligible to wayland-protocols at all, and there I think
we could be very lenient: anything that has a prospect of being used by
more than one software project.

The disadvantage is that we may collect a huge number of extensions of
varying quality. We must find a way to distribute the reviewer and
maintainer load, but I think that is doable with contributor guidelines
and giving out push access as Daniel says below.

How would people recognise the quality level of a Wayland extension
then, if the bar of entry is very low?

- Look at which projects are listed as implementing or refusing the
  extension.

- Look at who the maintainers for the extension are, if you know their
  personal reputation.

- Additionally, if wanted, we could even add "reviewed-by" entries to
  the extension meta data in addition to the maintainer entries, if
  people want to promote their endorsement of an extension.

In the end, the question may not even be about quality but design
goals. An extension itself may be of high quality even if the goals of
it are rejected by some.

Once we have that information in machine readable format, we can
generate various lists: extensions supported by most compositor
frameworks, extensions supported by most toolkits, extensions supported
by a specific compositor or toolkit, etc.

> 
> 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?

I think the aspiration is good, just that your proposal might not take
it quite far enough. The community around Wayland at large can never
fully agree on everything, so I think we should thrive to document the
differences in opinions.

Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20190221/b60d9bf7/attachment.sig>