State of Wayland protocol development

[Jonas Ådahl]

Hi,

I'd like to start a discussion on the state of how development of Wayland
interfaces are done and how they should be done, though less about the
technical aspect of it.

Right now, the way to get a protocol officially declared stable is, more
or less, to implement it in weston, wait for a while maybe making
changes, and then when agreed upon moved to the wayland repository. While
being in weston, the corresponding .xml file may have been copied to some
other repository for being implemented elsewhere (as it should be). So
far I only know of one protocol that has gone through all the steps
(wl_subcompositor), the rest are still in weston or in the mailing list.

Private protocols (for example gtk_shell) go through their own procedures
and I don't intend cover such protocols here. I'm also don't intend to
cover the desktop shell protocol core development that has been brought
up before[0] because it has other requirements, such as the fact that
without a shell protocol, a client cannot really do anything. Future
generic extensions to a stable xdg_shell are relevant here though.

A problem with the procedures we have is that it may be very hard to get
any protocols past the first step (posting to the mailing list), making
experimental adaptation harder, because the lack of versioning and the
fact that one would need to make a guess at what mailing list post is the
correct one at the moment. The reason for this I would say is unclear
requirements and expectations on what an unstable/experimental protocol
is, as well as unclear responsibilities on what group of people are
considered gate keepers of protocols.

In some cases, it may be more or less harmless to take a pending
experimental protocol and release it as an experimental feature. We
(GNOME) did this with pointer gestures, adding the latest version to
mutter and GTK+ in order to provide it as an experimental feature. The
problematic thing being that since, even though it is a generic protocol,
it does not have an "official" protocol version released anywhere even
though it is in use in a software release. While I believe it was pretty
harmless this time, I don't think this is a generally good way to do
things. For private protocols, within a private namespace, it is of
course the proper way to do it, but otherwise less so.

So, how can we improve these procedures?

We could introduce a wayland-protocols that contains future stable
protocols as well as staging / experimental protocols, while only
installing stable ones. Weston, mutter, GTK+, kwin, etc would depend on
it, but for experimental protocols the .xml files would still need to be
copied, because otherwise one would have to depend on a specific release
since experimental protocols are not necessarily backward compatibility.
This would allow us to release protocols without having to wait for a
wayland/weston release cycle, and we wouldn't need to wait for an actual
implementation in weston to get a central point to keep track of
protocols in development. It could just as well be split into the wayland
or weston repositories just as it is now if the intention is to have the
same release schedule.

The main issue, I believe, is that we lack defined procedure and agreed
upon requirements for what may actually be placed in such a repository. I
don't think it makes sense to have a sandbox protocol repository for
things like this; I think we need some system similar to what we have
with required review and discussion, and initial iterations and releases,
but I believe the pace of letting experimental protocols in and be
tracked not only on a mailing list, with proper versioning etc, is too
slow right now, and somehow we need to fix that.

Do we need more people who should be considered gate keepers? Right now,
as far as I understand it, Pekka and Daniel are the ones who currently
are the de-facto gate keepers of actual protocol changes / additions, but
given how things look, should we consider defining some requirements for
releasing experimental / staging protocol versions, such as R-B's by at
least N out of a set of persons, and expanding this set of persons to a
few more? (Note that I'm not blaming anyone for taking time etc, I
completely understand the lack of time available to spend on reviewing
protocols and protocol implementations). For declaring a protocol stable
there should of course be stricter requirements than for experimental
ones, but also here we need to reconsider how we should do things
differently regarding changes/additions to already existing interfaces.

What are the opinions of others here regarding this? Do we need to make
some procedural changes and if so what kind? Or are things working good
enough as they are?


Jonas

[0] http://lists.freedesktop.org/archives/wayland-devel/2015-April/021465.html