On Tue, Sep 17, 2019 at 05:46:49PM +0000, Simon Ser wrote: > On Friday, September 6, 2019 10:45 AM, Jonas Ådahl <jad...@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel