State of Wayland protocol development

[Pekka Paalanen]

On Fri, 18 Sep 2015 15:00:19 +0800
Jonas Ådahl <jadahl at gmail.com> wrote:

> 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.

Right, so should we be merging protocol proposals on much lower
barrier, while agreeing on how we are going to communicate breaks in
those protocols when they are developed and their current status?

Sounds like a good plan to me, with the condition that changes to
Weston's relatively stable parts must still be as carefully reviewed as
usual. This would still lift the burden of ensuring a protocol is good
before merging it.

If the protocol implementation details are well separated, maybe even
in a plugin, then we could just land it with mostly acks.

All this requires clearly denoting which parts are more stable and
which are considered experimental within Weston, both protocol files
and implementations. Directory structure? Protocol interface names?


Would it make more sense to have a repository separate from Weston for
the protocols? *shrug*

Should we allow merging protocols into Weston without an implementation
in Weston? Well, if you need a single central repository, and you are
usually expected to give a Weston implementation sooner or later, then
why not.

Is using Weston repository for protocols the right place? Considering
the files should not be installed, but they mostly expect to have Weston
implementations, yes. Would this be too slow? Well, there are people
with push rights around, and if we agree on very loose requirements on
pushing experimental protocol patches, maybe it wouldn't be too slow.

Should we be using a different Weston branch for including all the
experimental stuff while leaving master for "stable development"? Nah,
I think that might become a mess.[*]


What do you do when you do a backward-incompatible change to a protocol?

- Rename the globals or the protocol file? This would make people think
  twice about the change as it would incur lots of churn in the code.
  The churn shouldn't be a problem for review, since we wouldn't review
  experimental implementations carefully. But it's still churn.

- Use the mechanism tried with xdg-shell? A request to make-or-fail a
  specific experimental version. This seemed like a good idea, we just
  have to document it clearly and make sure it's followed properly.
  E.g. the make-or-fail request *must* always be opcode 0. We could
  have helpers for that.

> 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.

Or if we don't want to copy files, maybe we could use a ./configure
option to point a build to checkout of the experimental protocol
repository? It does have it's drawbacks, though.


Btw. I have been thinking that when one stabilizes a protocol extension
and moves the .xml file into the Wayland repository, we should also
always rename the global interfaces and the .xml file. This would be
the last protocol break, that allows us to remove any make-or-fail
requests while also ensuring no-one will accidentally use it with old
code, and it won't clash with any copies of the experimental xml file.


[*] Hmm, on second thought, would it really? That's what topic branches
are for, right? What if we did aiming-for-core protocol extensions in
Weston topic branches? That way once the day comes to stabilise that
extension, we can easily see what the patch to implement it in Weston
looks like - it's just a merge away.


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/20150918/b4fb915e/attachment-0001.sig>