wayland-protocols scope and governance

[Jonas Ådahl]

On Tue, Sep 17, 2019 at 05:46:49PM +0000, Simon Ser wrote:
> On Friday, September 6, 2019 10:45 AM, Jonas Ådahl <jadahl at gmail.com> wrote:
> 
> > >                       2.2. Protocol inclusion requirements
> > >
> > >
> > > a. All protocols found in the "xdg" and "wp" namespaces at the time of writing
> > > are grandfathered into their respective namespace without further discussion.
> > > b. Protocols in the "xdg" and "wp" namespace are eligible for inclusion only if
> > > ACKed by at least 3 members.
> > > c. Protocols in the "xdg" and "wp" namespace are ineligible for inclusion if
> > > if NACKed by any member.
> > > d. Protocols in the "xdg" and "wp" namespaces must have at least one open-source
> > > client implementation & two open-source server implementations to be eligible
> > > for inclusion.
> >
> > Maybe this was discussed in the past, but why two? If we'd travel back
> > in time, it'd stall the introduction of xdg-foreign (took quite a while
> > for a second server implementation to show up), which falls within the
> > xdg namespace scope, and it'd block addition of protocols only
> > interesting to a single compositor but multiple clients/toolkits (e.g.
> > something very tiling specific that maybe only wlroots would care about,
> > or something currently in gtk-shell that may be relevant for GNOME
> > Shell, gtk and Qt, but not for other compositors).
> >
> > Same for protocols like the tablet interface; I think it's too much of a
> > requirement to require the protocol author to provide TWO
> > implementations for such a protocol, and relying on others to implement
> > your protocol in their own compositors is quite a lot to ask IMHO. The
> > end result is more likely we end up with more things like
> > `gtk_primary_selection` instead of going upstream first.
> 
> That's a very fair point. I think it would make sense to require more
> implementations for unstable → stable upgrades (which are very
> important, we can't fix those later). But for unstable protocols, you
> do have a point.
> 
> I guess the original intention was to make a difference between xdg/wp
> inclusion and other namespaces: it should be harder to get a protocol
> merged in xdg/wp.
> 
> Thoughts?

I think both for stable and unstable the same limitation can be
as problematic. A protocol that fits in xdg/wp may still only be
relevant for a single compositor and multiple toolkits, or vice versa,
even when declared stable. Seems to me like the wrong method to keep
quality of wp/xdg protocols high.


Jonas