wayland-protocols scope and governance

[Mike Blumenkrantz]

Hello,

On Thu, Feb 21, 2019 at 10:47 AM Daniel Stone <daniel at fooishbar.org> wrote:

>
> One of Weston's goals is to be a reference compositor. As an active
> implementation, it serves as a useful neutral ground for the rest of
> the ecosystem: we try to be exhaustively correct in what we do
> implement, and gets used as a litmus test for clients and compositors
> both to compare their behaviour against (who's interpreted the spec
> incorrectly?). We take that responsibility pretty seriously, which
> places a ceiling on the rate of change as well as the breadth of
> functionality we can implement.
>
> There used to be a rule (observed in all but extremis) that any common
> protocol had to have a Weston implementation, as the closest analogue
> we had to a conformance test suite. That was abandoned long ago, since
> there are some protocols for which it wasn't practical to do so. That
> was the point beyond which we moved from Weston being _the_ reference
> compositor for the entire ecosystem, to just being a useful resource.
> (I get that Weston's README still says 'Weston is the reference
> implementation of a Wayland compositor' as literally its first words.
> I'd personally be OK with changing that.)
>
> Weston is also useful as a demonstration vehicle for new low-level
> graphics functionality, particularly for EGL and KMS features. We were
> the first to do overlay planes, full damage tracking (and now
> per-plane KMS damage tracking), dmabuf, buffer modifiers, explicit
> fencing, atomic modesetting, same-CRTC clone mode (AFAIK),
> aspect-ratio modes, and so on. I'm pretty happy with how that's going,
> even if we do still have some feature gaps.
>
>
Speaking on an entirely personal level (i.e., unrelated to any project or
employer) and as someone who has spent an amount of time writing both
compositors and clients using Wayland protocols--and also writing those
protocols, I found this to be very accurate. My ability to successfully
implement protocols in compositors and clients has benefited tremendously
over the years from the existence of Weston and its clients, even despite
their noted shortcomings. I'll also go a step further and challenge anyone
who has done similar work to deny having similarly benefited from Weston.

If anything, I think devoting more time and energy to improving Weston and
underlying layers would only serve to help the Wayland-using community.
Better documentation and better reference code lowers barriers to entry and
improves the ecosystem: this is something I know all too well from some of
the projects that I've worked on.


Regards,
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20190221/1a046dc5/attachment.html>