wayland-protocols scope and governance

[Daniel Stone]

Hi,
Just replying to Drew's mail since it's the most substantive. It seems
like things have petered out a fair bit. Having someone write up a
strawman CONTRIBUTING doc would be great. I'd love to do that myself,
but have been travelling this week (& on holiday for the next few
days), so not sure when I'd get to do it.

Another thing which would be really useful is for someone to take a
stab at the web page suggestion. You can just fork
https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org into
your personal namespace, then edit .gitlab-ci.yml to ensure that the
desired output lands in the public/ folder. After that you'll be able
to see the results by going to Settings -> Pages on the repo and
following the link. I don't think this should be blocked on figuring
out the exact details of the governance model: if we already have that
ready to go, then all we need to do is the appropriate small tweaks
when we finalise things. I don't expect to have time to do this any
time soon; I can certainly help others through it if you have issues
or questions, but volunteers would be very much welcome.

On Fri, 22 Feb 2019 at 02:39, Drew DeVault <sir at cmpwn.com> wrote:
> 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.

Good question; I'm not really sure what the right balance is. On one
hand, it's a good point about the divergence of client capabilities.
On the other hand, separately listing every background display, idle
monitor, screen locker, etc, is going to result in a really big list.
Maybe that's desirable, but it's certainly more challenging to
maintain (and, depending on our governance model, perhaps govern too).

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

If they're happy for you (or wlroots as a project) to speak for them
all, then I have no problem with it.

> > 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 agree so massively with Jonas that I'm going to quote him here:
J> I think formalizing a set of categories, including wp_ and xdg_ and at
J> least a third one is a good idea. I think that with a "free for all"
J> method suggested by Pekka, where we put all the responsibility on
J> everyone else to figure out what protocol fits under what category
J> (because there will still, in practice, be categories, we just avoid
J> spelling them out), we loose too much in terms of discoverability and
J> perceived scope. It'll be harder to know what to expect.
J>
J> What I mean here is that it should be clear what protocols are
J> "plumbing" (e.g. wp_viewporter), what protocols are for window
J> management related tasks where the application aim to be portable in a
J> sense that they will work on both fully integrated and non-integrated
J> compositors (e.g. xdg-shell and xdg-decoration), as well what protocols
J> are for applications that want to be a building block of a
J> non-integrated compositor (e.g. the layer shell protocol). I don't think
J> it's possible to avoid politics completely here, no matter how
J> "annoying" it is, because protocol development is partly about that.
J> There are most likely good reasons Khronos have chosen to work like
J> this as well.
J>
J> A protocol support matrix will still be very useful here either way, and
J> I expect all categories will include protocols with varying support, as
J> so is the situation already, but it wouldn't be the only source of
J> clarity of scope and potential adoption.
J>
J> We could also keep the door open for other groups of protocols, such as
J> IVI and maybe even those for fully coupled systems like the content
J> protection protocols that has been floating around, assuming those who
J> write protocols agree to act as maintainers and use our versioning
J> system.

Under what he's describing, xdg_shell isn't miscategorised, because it
_is_ the thing that everyone agrees on and uses. If we reserve xdg_*
for uncontroversial/unvetoed things, then xdg_shell would presumably
be a part of that. I think xdg_shell's primary focus is definitely the
desktop, and it's pretty unapologetic about that, but there is enough
wiggle room that it's usable way beyond the desktop. Same thing with
the XDG specs, where the ICCCM is useful for kiosks, .desktop files
are useful for phones, xdg-basedir is useful for display walls, etc.

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

Yeah, thanks for that. I don't think Weston should have a privileged
or unique role in protocol governance, but equally nor should it have
a diminished one. The choice of wording in 'the reference compositor'
is unhelpful and misleading nowadays, as is the conflation of the
Wayland and Weston websites etc, but these are all things we can fix
pretty easily, and we definitely have the will to fix and untangle
them.

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

Mm, but then shell is agreed on by everyone? Even IVI moved over to
xdg_shell for clients. Who do you have in mind who feels very strongly
about not using it?

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

Sounds good, or maybe for consistency we could just treat members like
the 'uncontroversial' protocol prefix space: proposed by an existing
member with no vetos from the others.

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

That sounds fine, but I'm not sure when I'll have time/bandwidth to
write up what I've put forward in this thread. I'd happily participate
in review of write-ups from anyone else though.

Cheers,
Daniel