wayland-protocols scope and governance

[Drew DeVault]

On 2019-02-21  3:47 PM, Daniel Stone wrote:
> Glibly, I'd probably just categorise the sway* clients in under the
> Sway/wlroots project, unless they had separate governance, opinions,
> roadmaps, etc? Similarly, I'm not sure there's much reason for us to
> separate the toytoolkit and simple-* clients from Weston.

This concept is somewhat alien to the all-in-one compositors like GNOME
and Weston, but the sway* clients are portable between compositors.
Users of Wayfire, Way Cooler, Waymonad, etc - are all able to, and do
use, swaylock, swayidle, and so on.

So is the list about structured governance, or about discovering clients
which will work on your compositor if you implement $protocol? For
example, I would not include swaybar, which depends on sway-specific
interfaces and doesn't work without them.

> wp_* governance has a part to play here as well. Is handing
> strong-veto rights to every small application the right thing to do?

If we're establishing a table, it may make sense to give wlroots as a
whole a seat at that table. wlroots is where the implementation lives,
after all, for all of the compositors who use it. We already kind of do
this with wlr-protocols.

> > What is the criteria for having a voice in this xdg namespace
> > "consensus"? This seems a bit opinionated and subjective.
> 
> Open question! It's a historical fact, for better or worse, that
> xdg_shell was basically developed and released between those three
> projects. Something different could definitely happen in future.
>
> One suggestion that came up was applying the same governance to xdg_*
> as to wp_*, so it would be like 'wp_* for window management'.

So there are two issues: the governance model of xdg, and the scope of
xdg. No objections to governing it the same way as wp, so long as we
make sure everyone has a voice.

The scope also seems fine, though if xdg-shell is meant to be useful
outside of desktops as you said, it's probably better suited for wp.
Since it's a stable protocol we'll probably have to acknowledge that as
an artifact of the past.

> I definitely have some thoughts [on Weston] %<

I apologise if I came across as disparaging to Weston, that wasn't my
goal. I too have found Weston useful as a reference and have a lot to
thank it for. I was trying to derive Weston's role in governance from
its goals, assuming these goals:

1. Be the reference Wayland compositor
2. Be a useful compositor in its own right
3. Be the basis for new desktop Wayland compositors via libweston

Sometimes these goals conflict, and Weston's role in governance might
change depending on which of these goals you're focusing on. It might
not be desirable to be a "political" entity to best fulfill goal #1.
Fulfilling goal #3 effectively might be best served by deferring
judgement to the compositors which are based on libweston. Goal #2 may
politically conflict with goals #1 and #3. And so on.

Daniel and I clarified this off-list, so I'll omit the longer
explanation and we'll just move foward under the assumption that Weston
ought to have as much of a role in Wayland governance as anyone else.

> Maybe, as Pekka said, that isn't workable and we should scrap the idea
> of agreed-upon prefixes and leave it a free-for-all.

Agreed-upon prefixes is probably a good idea, assuming we can find
agreement.

> > 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.
> 
> XDG is already overloaded enough that I'd like not to add 'stuff some
> people use but others feel very strongly about not using' to it. Some
> people also interpret XDG to mean 'freedesktop.org Certified Seal of
> Approval™', which is ... sort of the opposite of that.

The frustrating problem is that xdg-shell exists and is stable and is
called xdg-shell. We should probably rename xdg-output, by the way,
before it becomes stable.

> Right. On the other hand, I also don't want to have to gatekeep
> development of protocols I have no interest in (even if it is just
> clicky busywork), and even protocols I do have an interest in. If
> we're lowering the barrier to entry and trying to raise our level of
> inclusion, we might as well deal with the bus factor whilst we're
> here.

Fair point. Once we establish a role for each prefix, then it might be
good to establish a group of stakeholders with commit access and a
gentleman's agreement between them to follow the rules we set forth.
As for membership in this group: I propose inviting a diverse group of
existing stakeholders, including at least the people we've already
talked about (let's add Smithay to that, too). Then new members can be
added by invitation from an existing member. If we have a large and
diverse enough membership, I'm less concerned about gatekeeping. If you
just have to convince at least one member to sponsor your membership,
then that's should be easy enough.

> To be honest, that sounds a lot like the development process we have
> already. If something is expected to be under heavy development and
> potentially need a lot of rework after implementation, then it can
> just live in a branch and people can pull it from the MR or whatever
> as they develop it in their (presumably also not merged) compositors
> or clients.

I don't think the development process we proposed now is one that
couldn't work - it just needs less gatekeeping. Also, I think that
merged and shipped protocols can still arguably live in the draft
namespace - kind of like how unstable protocols work today. Either that
or...

> I think the 'z' prefix and general unstable versioning rules work well
> here.

We could lower the bar for unstable protocols living in more "upscale"
namespaces - which might also be a good idea. Perhaps we can be lenient
with unstable protocols and namespaces, then add more pomp and
circumstance to promote them to stable.

> If multiple people have implemented a protocol and are sharing it,
> then (taking 'ext' as a strawman for
> not-wp-but-not-single-project-either) it would be zext_redshift_v1. If
> single projects wanted to push something, then they could push it
> under their own namespace, e.g. zmutter_animation_control_v1, but at
> that point it's not really clear what benefit there is to it being in
> wayland-protocols master. At that stage of development, it's probably
> going to be more of a hindrance having to observe the versioning and
> stability rules.

ext sounds like a good alternative to xdg for the kitchen sink. I want
to move away from compositor-specific prefixes, though.

In the interest of establishing a path for this discussion towards an
actionable conclusion, I'd like to suggest that each stakeholder
interested in making a proposal for the governance model puts together a
formal proposal, then we can bikeshed those a bit more and put it to a
vote. Not to rush things, to be clear, there's a lot more discussion to
be had before you can expect such a proposal from wlroots.