wayland-protocols scope and governance

Fri Feb 22 13:22:23 UTC 2019

On Thu, 21 Feb 2019 18:11:46 +0100
Jonas Ådahl <jadahl at gmail.com> wrote:

> On Tue, Feb 19, 2019 at 04:50:27PM +0000, Daniel Stone wrote:
> > Hi all,
> > I'd like to open up a discussion on enlarging wayland-protocols to a
> > wider audience, with a better definition of what it contains.

> > My second suggestion is to formalise the 'xdg' namespace. xdg
> > extensions have been accepted or rejected by rough consensus between
> > Enlightenment/EFL, GNOME, and KDE. That still seems reasonable enough
> > to me, assuming that 'xdg' retains the focus of an integrated (as
> > opposed to build-it-yourself) desktop. The IVI namespace would
> > similarly be delegated to automotive people, and maybe we could
> > delegate the layer_ namespace to those developers as well.
> > 
> > My third suggestion is to formalise the 'wp' namespace, as core
> > extensions that everyone can agree on. It doesn't mean everyone needs
> > to implement them, but at least not have active opposition. For
> > example, Mutter hadn't implemented wp_viewporter for the longest time,
> > but also had no opposition to it being implemented - which wouldn't
> > block it being a 'wp' protocol. Or Weston hasn't implemented
> > xdg_foreign and probably won't, but I'm fine with it existing and
> > being a common extension. On the other hand, Weston/Mutter/etc would
> > have very strong opposition to a 'wp_randr' extension, and last I saw
> > wlroots would have very strong opposition to wp_pointer_gestures. So
> > those wouldn't be wp.
> > 
> > So where does that leave other extensions? My fourth suggestion is
> > that we look to the OpenGL/EGL/Vulkan registries: if an extension has
> > been vetoed from the wp_ namespace, but still had support and
> > implementations from multiple projects, that we still accept and
> > publish it under a different namespace which makes it clear that some
> > projects think the extension is fundamentally a bad idea, but it is
> > also not a compositor-specific extension. Bikeshedding the prefix to
> > use here would be welcome, as I don't have any good suggestions right
> > now.  
> 
> I think formalizing a set of categories, including wp_ and xdg_ and at
> least a third one is a good idea. I think that with a "free for all"
> method suggested by Pekka, where we put all the responsibility on
> everyone else to figure out what protocol fits under what category
> (because there will still, in practice, be categories, we just avoid
> spelling them out), we loose too much in terms of discoverability and
> perceived scope. It'll be harder to know what to expect.

Hi,

if the categories can be formalised and agreed upon, with "ext" or
something for "the rest", that would be brilliant.

My counter-proposal was on the pessimistic side of that ever happening,
I have no objections to having namespaced categories otherwise.

> What I mean here is that it should be clear what protocols are
> "plumbing" (e.g. wp_viewporter), what protocols are for window
> management related tasks where the application aim to be portable in a
> sense that they will work on both fully integrated and non-integrated
> compositors (e.g. xdg-shell and xdg-decoration), as well what protocols
> are for applications that want to be a building block of a
> non-integrated compositor (e.g. the layer shell protocol). I don't think
> it's possible to avoid politics completely here, no matter how
> "annoying" it is, because protocol development is partly about that.
> There are most likely good reasons Khronos have chosen to work like
> this as well.
> 
> A protocol support matrix will still be very useful here either way, and
> I expect all categories will include protocols with varying support, as
> so is the situation already, but it wouldn't be the only source of
> clarity of scope and potential adoption.
> 
> We could also keep the door open for other groups of protocols, such as
> IVI and maybe even those for fully coupled systems like the content
> protection protocols that has been floating around, assuming those who
> write protocols agree to act as maintainers and use our versioning
> system.

For now, I'd just stuff content protection to "ext". I can't see it
growing to be a big enough family to have its own namespace. The same
for IVI. Keeping the door open is easy, definitely, maybe something
completely different comes up.

> > 
> > Once we've established and codified these ground rules - with a
> > document along the lines of Wayland's CONTRIBUTING.md - we can open up
> > commit access to wayland-protocols, so we're not so reliant on a
> > couple of arbitrary gatekeepers. Obviously this would be done with the
> > expectation that those ground rules are followed - don't post a wp_
> > extension on a Sunday morning and then commit it in the evening with a
> > couple of +1s because no-one objected - but we're all reasonable
> > adults, and can treat each other reasonably without having to enforce
> > ACLs.
> > 
> > Does anyone have any thoughts or suggestions here? Is this a good
> > aspiration? Is it the best way of achieving that aspiration?  
> 
> There is also the question about what model of contribution and
> discussion we should use. Do we rely on merge requests, keeping
> discussions there, or do we stay on the mailing list using
> git-send-email?

I'd go Gitlab all the way. Now that I've been working with Gitlab on
Weston and Mutter for some months, the email workflow is much more
painful, even when I've been on the email workflow for years and I
already have all my scripts set up etc.

Not to mention the increased challenges of running mailing lists at
fd.o I've heard about recently.

The only things that don't seem to fit in Gitlab too well are
announcements and questions.

> IMHO we should choose one or the other, not some combination where
> Gitlab sends E-mails to the mailing list for merge requests, as this
> would mean we'd end up with multiple diverging versions of the same
> discussion thread.

Yup.

I think Jonas' email here gathers all the ideas I would be happy with,
now that I've read the other replies as well to get a better
understanding on where we might be going.

Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20190222/757f489f/attachment.sig>