Are the stable/staging/unstable protocol distinctions useful?

[Neal Gompa]

On Fri, Jul 7, 2023 at 6:32 AM Pekka Paalanen <ppaalanen at gmail.com> wrote:
>
> 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.
>

Maybe consider an automatic promotion process instead? There's no harm
in promoting standards that aren't changing. Ultimately, even
"unstable" protocols don't get incompatibly changed without a version
bump, so I don't really feel like the current classification model is
meaningful.

Promoting after two wayland-protocols releases of no significant
changes would hopefully be a decent indicator of "stability".

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

But we could stem the bleeding and do an artificial version bump to
eliminate the unneeded labels, couldn't we?

The number of protocol implementers are small enough right now that it
is potentially possible to fix this, though arguably it should have
been fixed long ago...

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

It's a really nice idea, shame it didn't happen. :(

That said, wayland.app is incredibly helpful in figuring out where
things actually are in the ecosystem.




--
真実はいつも一つ！/ Always, there's only one truth!