Are the stable/staging/unstable protocol distinctions useful?

[Pekka Paalanen]

On Thu, 6 Jul 2023 18:44:16 -0400
Neal Gompa <ngompa13 at gmail.com> wrote:

> Hey everyone,
> 
> There's something I've been ruminating on for a few years now: the
> state of wayland-protocols.
> 
> I've noticed that over the course of the existence of
> wayland-protocols, only three have made it into "stable":
> presentation-time, viewporter, and xdg-shell.
> 
> But basically no useful Wayland environment relies only on those three
> protocols, and many protocols have been broadly adopted in staging and
> unstable. For example: everyone implements relative-pointer (unstable)
> and almost everyone implements xdg-activation (staging).
> 
> There are many "unstable" wayland protocols that are so broadly
> adopted that they basically aren't going to change anymore. A good
> chunk of the "staging" protocols have no implementers (per
> wayland.app).

Right. See e.g.
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/223
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/221#note_1985498

> So what I'm wondering now is: are the distinctions useful? And if so,
> how are they useful? If they aren't useful, can we get rid of them?

The distinction they make is:

- unstable/staging are kind of incubating, meaning they have higher
  chance to need a new backward-incompatible revision than stable

- unstable/staging have a higher chance to lose support after being
  implemented than stable

"Higher chance" also implies that suggestions to do so are more
acceptable than in stable. That means that the incentive to bend over
backwards to work around any design warts is much lower.

The difference between unstable and staging was just the process on how
an extension shall be declared stable. Unstable mandated a final
world-breaking change while staging does not. Today, I think both are
equal in that we would always use the staging process.

Our failure here is that there is no clear criteria when an extension
needs to move to stable, so they have mostly been forgotten since stuff
works already.

> Now, that may seem nuts, but here me out! Every wayland protocol that
> has been merged is already versioned. Every wayland protocol proposed
> is supposed to already have at least two implementers (which as noted
> earlier, a number of existing protocols lack).
> 
> Between the versioned protocols and the requirement for implementers,
> I don't see where the distinction helps anything. If anything, I've
> seen examples of the distinction used as a deterrent by particular
> compositor implementers despite the obvious need for them.
> 
> Could we consider getting rid of the distinction? If we need to have
> structural sorting in the repository, perhaps folders representing the
> versions instead? Or maybe some other categorization that doesn't
> imply that something shouldn't be implemented.

A good question. If staging prevents an extension from seeing interest,
it will never prove the design either.

OTOH, I suspect a concern was that people would jump to implementing
something assuming it's final, and when upstream decides it doesn't
work right and needs a breaking change, people could be upset.

There are few extensions that probably shouldn't be newly implemented
by anyone. Fullscreen-shell comes to mind.

Nothing can be deleted, because it would break builds, so the
directories will live on anyway, but it would be possible to realize
the old directory structure at install time, like Sebastian recently
suggested.

I suppose a much more useful distinction than staging/stable would be
a database indicating which software implements what extension. That
has been on a wishlist for years, including recording project attitudes
towards extensions (will never implement vs. ok but no-one did the work
yet).

wayland.app looks really nice, but I think the implementors list should
also include client toolkits and perhaps version information.

This was the plan that never came to fruition:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/master/GOVERNANCE.md#3-protocol-adoption-documentation


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/20230707/68bc3f10/attachment.sig>