Where should project Weston go?

[Pekka Paalanen]

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.

I feel the need for it, because I personally find it sometimes hard to
judge whether a big new feature is a good idea or out of scope.
If I am lacking a clear vision, I can only imagine it is even harder
for others to decide, and I believe lack of vision can also hinder our
patch review. It is too easy to postpone reviewing a patch series
if one is not completely sure it belongs in Weston.

Our website defines Weston as follows:

"Part of the Wayland project is also the Weston reference
implementation of a Wayland compositor. ... The Weston compositor is a
minimal and fast compositor and is suitable for many embedded and
mobile use cases."

To reiterate the main points:
- the reference implementation
- minimal
- fast (performant?)
- suitable for embedded and mobile (and now automotive?)

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.

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.

The libweston effort by Giulio is set to solve some of those problems. I
suggested that every minor (not micro) version of libweston needs to be
cleanly parallel-installable. This will make it easier for
distributions to ship multiple Weston-based DEs even if their required
Weston versions differ.

Then again, why was IVI-shell merged? My own opinion is that IVI-shell
serves the embedded (automotive) space. The people pushing it had a
strong will to see it upstreamed to Weston, and I have understood they
are committed to maintaining it. It's not just a code drop, there is
more to come. I hope that it will also bring new contributions and new
contributors for all over Weston, benefiting also the desktop.

IVI-shell is also, for a long time or maybe ever, the first non-desktop
shell in Weston intended for applications and not mostly for nested
compositors like the fullscreen shell. It helps to clarify the concept
of shell (protocol).

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?


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. To
make it easier to step forward and take a bit of responsibility as a
reviewer, I wrote this email to query and set up the community
expectations.

Note, that even though I'm interested in the concensus, it is not one
person, one vote. The vote is weighed by the person's track record, as
in most open source projects.


Thanks,
pq