State of Wayland protocol development

[Jonas Ådahl]

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?


Jonas


* 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