wayland-protocols scope and governance

[Drew DeVault]

On 2019-03-08 11:28 AM, Daniel Stone wrote:
> > 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.

I spoke with everyone and we're in agreement on this point. We can
always split into more entities later. However, based on this we ought
to be careful with anything like voting where a majority or percentage
of members is required. We wouldn't appreciate exchanging voting power
for convenience.

> 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 still maintain that xdg-shell is somewhat shoehorned in for cases
which are not the desktop. But that's kind of what I'm getting at:

> I think xdg_shell's primary focus is definitely the desktop

and

> [xdg-shell] is the thing that everyone agrees on and uses. If we
> reserve xdg_* for uncontroversial/unvetoed things

These are in conflict. There are protocols which are unsuitable to the
desktop, like IVI shell, which may nevertheless have unanimous support
among the compositors which use it. I could see more shells being made
in the future, particularly for mobile, as I don't think xdg-shell is
designed with mobile well enough in mind. In other words: xdg cannot at
once be the unanimous view of all of Wayland and a desktop-centric
namespace.

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

Me :)

I were to make a mobile compositor (and I very well might) and I was
willing to patch clients with support for a new protocol (doubtful), I
think I would do that before I'd use xdg-shell. The main issues that
come to mind are:

- Interactive move/resize probably doesn't make sense on mobile.
  xdg-shell was influenced by parties who are strongly in favor of
  client autonomy, but on mobile there's really no reason for me to let
  you move or resize yourself on a tiny screen. You get 100% of the
  screen whether you like it or not, and this protocol doesn't
  acknowledge that possibility.
- set_parent doesn't generally make sense on mobile

"Strong" is the wrong word to describe these opinions. In practice I
would probably end up using xdg-shell on a mobile compositor because
it's definitely Good Enough. I just want to take xdg-shell off of this
pedistal and make an example of it for illustrative purposes.

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

I don't like the idea of giving out veto power. Perhaps rejecting
inclusion given some minimum number of NACKs would be better.

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

ack

Aside: what if we deal with namespace inclusion by using NACKs to
express disagreement on categorization? A protocol could be added to any
prefix given it meets these criteria:

1. It has an implementation
2. The authors deem it worthy of inclusion

In practice I hope these criteria wouldn't have to be appealed to, and a
discussion among members on why the protocol should or should not be
added to a namespace would be fruitful. However, if consensus cannot be
reached then the protocol database would be updated to reflect the
protocol author's wishes nevertheless, and the dissentees would be
allowed to express their dissent through NACKs, which appear on the
website (and perhaps can include a small blurb explaining the
rationale). In this way, the website reflects reality moreso than
politics: the authors of the contentious protocol are going to use it
and implementations are going to proliferate even if consenses is not
reached, and therefore the website faithfully documents that protocol's
real-world usage; and those who raise an objection to it have a place to
make their case to anyone interested in that protocol.