Where should project Weston go?

[Tanibata, Nobuhiko (ADITJ/SWG)]

> -----Original Message-----
> From: wayland-devel
> [mailto:wayland-devel-bounces at lists.freedesktop.org] On Behalf Of
> Pekka Paalanen
> Sent: Monday, December 08, 2014 9:02 PM
> To: wayland-devel at lists.freedesktop.org
> Subject: Where should project Weston go?
> 
> 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.
[ntanibata] Thanks for starting discussion!

> 
> 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
[ntanibata] In automotive, "minimal" might be equals with compliance definition of e.g. GENIVI.
The compliance is strictly maintained by GENIVI and it can clearly say what "minimal" is.

> - 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?
[ntanibata] From automotive, there is clear definition of compliant so drawing line might be more easy than desktop.
Compliant first and optimize "fast" with keeping compliant.

> 
> 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.
[ntanibata] Exactly. I believe there is no huge additional feature on ivi-shell because the compliant is already fixed in GENIVI. However if many users will indirectly use Weston core via ivi-shwll with automotive use case, many suggestion will come for Weston core to make it best reference implementation.

> 
> 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?
[ntanibata] One of expectation from automotive; Weston core with a shell would experience actual products and get feedback to be confident that the first reference implementation of wayland compositor.
> 
> 
> 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.
[ntanibata] I would join review. Topic of maintainership, I think, it shall be discussed more.

Best regards,
Nobuhiko Tanibata

> 
> 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
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel