Clarifying scope and goals for weston

[Pekka Paalanen]

On Wed, 17 Apr 2013 16:34:19 -0400
Kristian Høgsberg <hoegsberg at gmail.com> wrote:

> Hello list,
> 
> A few weeks ago, Thiago Maciera sent out a good email about patch
> review and how everybody can help with the review effort:
> 
>   http://lists.freedesktop.org/archives/wayland-devel/2013-March/008174.html
> 
> I see more reviews on the list now and I really appreciate that;
> thanks to Thiago for writing the email and to everybody who has jumped
> in and reviewed patches.  However, Pekka brought up a good point:
> 
>    "Anyone can review coding style, but what if we massage coding
>     style and other minor details back and forth a lot, and then
>     someone does a proper subjective review NAK'ing the whole idea, or
>     at least forcing a complete rewrite. Is that review and
>     improvement work wasted for nothing, or is it useful?"
> 
> Fortunately a lot of patches are easy to review and accept - bug fixes
> or fleshing out FIXMEs or a self-contained new backend for example.
> Patches that add features or change established behavior are typically
> less obvious and in those cases it's of course good to first try to
> determine whether the overall idea is right.  To that end, I'd like to
> see if we can all agree on the scope of weston.
> 
> Part of the confusion around this is that weston started out as just a
> way to verify the protocol as well as gbm, KMS, evdev etc integration,
> which implies that it's throw-away code or at best a source for copy
> and paste.  On the other end of the scale, what weston is today is
> obviously a lot more than just sample code, we even have a toy desktop
> that makes it look like it's a real desktop environment.
> 
> In my mind, the main output of weston is the core compositor and the
> plug-in API.  We have a very efficient GLES2 renderer, very good KMS
> integration and overlay usage, and a good input stack.  We have good
> infrastructure for writing custom backends and a flexible way to
> plug-in a higher-level shell component to handle window-manager-like
> responsiblities.  This is the part of weston I consider product
> quality and we have to maintain high standards when working in that
> area - strict error checking, handle all corner cases etc.  The core
> compositors goal is to be a base for other projects, similar to how
> the X server isn't a full desktop environment or mobile/embedded UI,
> but a core technology to build one upon.  It is also still the
> reference implementation and must implement and exercise all core
> protocol.
> 
> The desktop shell in weston serves three goals: to validate wl_shell
> protocol, to make weston do something useful when you start it up, and
> to provide a reference for how to implement a shell module.  The
> desktop shell is not supposed to be a generally useful desktop
> environment.  When we're implementing something for the weston desktop
> shell, we go for simplicity and protocol coverage rather than full
> configurability or external dependencies.

Would it be possible to say something about when feature additions
might be rejected, more than just referring to configurability or
features requiring new external dependencies?

It seems to be very difficult to draw the line here.

> As for xwayland, I'd like this module to be better quality and provide
> easy integration of X applications for UIs that build on weston.  As
> it is, it's rather spotty in its support for ICCCM and EWMH though,
> and mainly serves as a validation effort for X integration.
> 
> Tell me what you think,
> Kristian

It is a nice clarification. I think something to this effect should
also be in the website, so we can easily point to it. It would also
automatically set expectations before people start implementing their
pet feature, while they are just learning about Weston. In email
archive this is too hard to find.


Thanks,
pq