State of Wayland protocol development

[Pekka Paalanen]

On Fri, 9 Oct 2015 14:41:31 +0800
Jonas Ådahl <jadahl at gmail.com> wrote:

> Hi again,
> 
> I implemented one of the brought up ideas to see how it'd work.
> More specifically, I created a repository called "wayland-protocols"[0]
> and adapted weston[1] to use it for the fullscreen shell. I also added 
> pointer gestures to make it obvious that its not only protocols that are
> implemented in weston that are part of it.
> 
> The way I imagine it would work is, for new protocols to be introduced,
> it'd have to be a agreed upon "correct" path (i.e. probably not
> wl_absolute_coordinates etc), which should simply mean that such a
> protocol should have been at least Acked-by one or more core developer
> that have acknowledged that it is a suitable thing to do in the Wayland
> ecosystem.
> 
> Protocol changes (including introduction) would also require
> Reviewed-by's by someone with enough knowledge*, and if a protocol has a
> maintainer(s), at least Acked-by one of them.
> 
> Releases of this repository would not be tied to releases of
> wayland/weston, and it wouldn't be a requirement to have a protocol
> implemented in weston to make it part of a wayland-protocols release.
> 
> Fast paced protocol development would be done on topic branches, and
> wouldn't be part of any release until properly reviewed. External
> projects would be encouraged to not release software releases that
> exposes such intermediate versions; if expected to use a common
> namespace, they should use a version from a wayland-protocols release.
> 
> Declaring a protocol stable could either be done by doing the renaming
> and moving it to wayland, or we could just move it to a stable/
> subdirectory in the same repository. I actually think this might be a
> better idea, so that we don't tie down protocol development to the
> reference compositor release cycle.
> 
> Patch merging could be done in the same way as with wayland/weston,
> assuming the patch merger makes sure the right persons have acked or
> reviewed.
> 
> Release management could either be done by the wayland/weston release
> manager or someone else. I could volunteer doing this if no one else has
> a strong urge.
> 
> For the more practical parts, the protocols in the repo now have
> versions in the XML file names and in the protocol element attribute, but
> not in the interface names. Having version numbers in the interface names
> would enable us to implement multiple versions in clients and servers,
> but it'd mean that each interface would have both a _ prefix and a
> version number. Maybe thats fine, and I wouldn't object if someone thought
> that would be better. It'd get rid of the redefinition of interface
> versioning for unstable protocols.
> 
> I still have the '_' prefix which, mentioned by Pekka, violates some
> rule in C. I'm not sure we need to care (we've been doing this in weston
> since 2013), but if anyone has a better suggestion or objection please
> say so.
> 
> FWIW, the way things are structured in the repo now, it is possible (and
> enabled) to install unstable XML files. Copying would work as well. All
> these these minor practical details I don't have a strong opinion on,
> and I'd be happy change them if needed.
> 
> If we want to take this path with a protocol repository, after agreeing
> upon the details, I'd continue with moving away the generic protocols
> from weston, applying some "unstable protocol" rule regarding xml,
> protocol and interface names, and change weston to start using files
> from wayland-protocol (copied or installed).
> 
> Thoughts?

I have no objections. Seems like it'd work. You have a different XML
file name for each incompatible version, so there won't the problems in
projects directly depending on this repo being checked out or installed.

If this really solves some problems we have, I'm all for it.

One thing we could add is a list of protocol maintainers if assigned,
so it would be clear who to get an ack from. I'd take wl_scaler,
presentation and dmabuf for starters.

I think this would nicely separate the protocol review from
implementation review, in case that has been a problem: if the protocol
has been merged in wayland-protocols master even if unstable, the
implementation in, say, Weston, only needs to be technically reviewed
and reviewers don't have to question the quality of the protocol spec
at the same time.

> * How to determine this I guess is one of the things that needs to be
>   agreed upon, but I imagine it'd be different set of individuals
>   depending on the area the protocol touches.
> 
> [0] https://github.com/jadahl/wayland-protocols (only on github for
>     demonstration)
> [1] https://github.com/jadahl/weston/commit/caf37bb527740b5792260deaabc1ce33678351e5

The idea of the Weston patch looks good to me too.

However, could we use git submodule to automate the fetching or a
recent-enough revision of wayland-protocols? It might prevent some
weston FTBFS questions, when we depend on unreleased versions. Or was
the idea to release wayland-protocols often enough so we could always
just rely on the pkg-config version check in configure.ac? That would
be fine too.


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