Where should project Weston go?

[Bryce Harrington]

On Mon, Dec 08, 2014 at 02:01:32PM +0200, Pekka Paalanen wrote:
> Dear Wayland community,
> 
> I would like to start a discussion on what Weston really is, and where
> it should go, if only to confirm that our concensus still holds.

Thanks for opening discussion on this.  I suspect a lot of us have been
pondering these questions for a while.
 
> To reiterate the main points:
> - the reference implementation

> - fast (performant?)
> - suitable for embedded and mobile (and now automotive?)

Performance is really only relevant in context to a use case; otherwise
this can lead us to pre-maturely optimizing stuff that no one cares
about.

So, maybe "fast for embedded/mobile/automotive".  Or maybe there's an
implied use case in the original statement (i.e. fast desktop) that
should be made explicit.


> - minimal

:-)  When I see a FOSS project describe itself as "lightweight" I read it
as "We consider our lack of features to be a Feature!"

But I imagine 'minimal' is intended here in more of an engineering
sense, and interpret it myself to mean something like: Focuses on
principle features not superfluous stuff better handled by other
projects; doesn't overengineer algorithms to squeeze a few drops of
performance; feature selection by what fits nicely and makes sense, not
by marketing demands; favors short and concise function implementations
that are easy to maintain and understand, even if it limits
performance/portability/features a bit.


> Weston is also a test bed for new protocols and features. We tend to
> land experimental protocols in Weston, try them out there (while in
> this stage, third party projects need to copy the XML files from
> Weston), and when they stabilize, we move protocols into the Wayland
> project and install the XML files from there for everyone to use.

Judging from what I've seen on the mailing lists there certainly is a
strong demand pushing weston to fulfil this role as a laboratory of
experimentation.

But Weston's development processes seem to be set up more for product
development than for freeform R&D.  Namely, we have one single "true"
tree with a gatekeeper to control what gets committed, reviewers to
catch quality issues, and a growing testsuite.

I'm not saying this is wrong, just that this is probably not ideal for
facilitating experimentation; folks may prefer to gravitate towards
other compositor development projects where they can turn ideas and
patches around more swiftly.  And that's not necessarily a bad
thing... but it's different than considering weston as a test bed.


> Perhaps the most striking omission in the above is that the desktop for
> PC is not mentioned. The desktop is in scope only through "the
> reference implementation". What does it mean?
> 
> I believe it means, that Weston needs to implement all the important
> desktop-related protocol extensions, obviously starting from xdg_shell.
> This is the reference implementation. However, other desktop-oriented
> protocol extensions might not be that obvious. How would we judge them?
> I guess it has to be case by case, which makes it hard for any one
> person to do.
> 
> On the other hand, it also means that Weston does not need to, and
> maybe even should not, implement many desktop features that do not
> include a protocol extension to be standardized across Wayland servers.
>
> Where to draw the line? How to keep Weston "minimal" and "fast", while
> we would likely want to make Weston more usable as a desktop server too?
>
> Should we add one more goal for Weston: a simple desktop environment?
> But how simple? Would it include, say, a tool to do permanent video
> mode changes? A real screen lock? A task list? Also see the note about
> "camp agnostic" below, which limits the realistic possibilities a lot.
> 
> Before one says "Yes!", we need to think about maintainability. Can we
> write a test that would run during 'make check' and see that the
> feature keeps on working? I agree with the saying that if something is
> not tested, you can assume it's broken. It is also a reason why I am so
> thrilled about the test suite improvements.
> 
> So far the desktop shell implementation in Weston has not been
> considered anything more than a reference implementation of
> wl_shell and xdg_shell. Proper, more user friendly DEs are external
> projects that build Weston plugins. A problem there is that if
> Weston has to have a feature that is not used from the Weston project
> itself, it may easily break. There is also the problem that the plugin
> ABI is not stable.

I've noticed over the years, that I can say until I'm blue in the face
that "Wayland is just a protocol, Weston is just a reference
implementation, and you need to look at desktop environments to provide
Wayland compositors;" but people still keep asking me, "Okay, but when
can I ditch X and just use Wayland as my desktop?"

Or the corollary: "If the Wayland protocol was finished some years ago,
and weston is 'just' a reference implementation, why is there still
development effort on it?"  The implication being that it's being called
a reference implementation much the way X.org is "just" a reference
implementation of X11.

There is a public [misperception?  expectation?  belief?] that Wayland
is a software product that will one day arrive and revolutionize their
desktop/smartphone/helicopter/dishwasher experience.  Or at least fix
some <mumble> problems that exist with X's architecture.


So I figure there's two options.  One would be to chase this public
sentiment and start handling Weston as a regular desktop server product
development effort.  Weston's focus would need to be restrained, as per
the other requirements, so the desktop use case would be limited to the
audience for "minimal/lightweight" (nvidia-free?) DEs.  If this is
successful, the law of the slippery slope will inevitably lead us to
implementing more and more features until it fulfills Zawinski's law.

The other option is to get weston's head and heart aligned, and
strengthen our focus on being "just" a test bed for improving the
Wayland protocol.  Give our community's primary attention not to
Weston's users but Wayland's users - Enlightenment, GNOME, KDE, and
other DEs.  Survey and study their requirements and look for things they
need across the board.  And make it easier for them to bring us their
problems/ideas/needs.  Make it convenient for people to do prototyping
and experimentation in Weston first, and then port to production
compositors, rather than vice versa.  Instead of unit testing weston,
improve the validation testing of wayland, such that the same testsuite
would run against the weston compositor, enlightenment compositor, et al
to verify that the DEs have properly implemented the protocol
requirements.  Instead of delivering a monolithic Weston package, turn
the best bits of it into specialized libraries that DEs can use too (if
they wish).  Define a clear process for 3rd parties to contribute
extensions, libraries, and driver support changes.  Finally, work to
change public perception to stop the expectations on producing
Weston-the-desktop, by vocally championing DEs that are already giving
solid Wayland-based desktops.


> Then what should we not put in Weston?
> 
> So far Weston has been kept deliberately "camp" agnostic, which means
> that dependencies to GNOME, KDE, E or similar "camps" are not allowed.
> In practice, Weston should never even optionally depend on GTK+, Qt,
> EFL, or such. Weston does optionally depend on glib, but I suppose that
> is acceptable considering the features depending on it. It has been camp
> agnostic to not favour any particular existing DE camp, and to not
> alienate any other DE camp.
> 
> I think walking that middle road has been good, and we should continue
> that.
> 
> What do you think what Weston should be in the future?

Because Weston has walked this middle road, it puts it in the position
of being able to serve as a standards body for the DE community.
Historically that's been a huge need but not always well delivered on.
freedesktop.org's mailman is thick with efforts that tried to establish
standard solutions to common needs, with successes ranging from full to
nil.  So, for the overall FOSS community we're in a very valuable spot,
that would be very hard to establish from scratch.

I'd love to see Weston become a proper desktop server, and think
personally it'd be fun to work on.  However, it could be counter
productive from a larger perspective.  Even if we refrain from using Qt,
gtk, efl, etc. the fact that we'd be making (and presumably promoting) a
usable alternative could be seen as disrespectful of the DEs that have
already done the implementation work for adding Wayland support.

Better might be to look for feature needs common to all the DEs that
could be candidate for addition to the Wayland protocol, or go into a
new or existing library that all DEs could share.  Weston's focus would
then be the R&D of those bits, and creating associated documentation and
validation testcases.


> Btw. I still would not claim to be *the* Wayland/Weston maintainer, even
> though lately I have practically been doing that as time permits
> (sponsored by Collabora). I would like to see more of capable people
> rising as reviewers and some through experience eventually to
> maintainership. I cannot do this alone forever like Kristian did.

I know from looking at patchwork lately how big of a workload this is
for one person.  I would be more than happy to lend a hand with
maintenance; I do maintenance on Cairo, am release manager for Inkscape
and used to maintain the X stack for Ubuntu, so have some experience
here.  Samsung has a strong interest in Wayland right now, so the
maintenance work would be a day job priority.

Bryce