Where should project Weston go?

Tue Dec 9 11:36:42 PST 2014

Bryce,
Thanks for your thoughts.  I've got a few of my own, but I decided to reply
to your e-mail as it seemed the best branch-point for the actual discussion
without replying to everything.

On Mon, Dec 8, 2014 at 3:26 PM, Bryce Harrington <bryce at osg.samsung.com>
wrote:

> 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.
>

I think that Weston's performance matters a lot in some respects and not
much in others.  We don't want to overcomplicate things by prematurely
optimizing or squeezing out every clock cycle we can.  However, Weston does
give us the opportunity to show off some of cool performance things the
Wayland protocol allows us to do.  One example of this is the planes
support in the drm backend.  Weston may be the only desktop compositor
around today that take a single subsurface out of a window, put it in a
plane, and flip it directly to the screen.  This is fantastic for
performance and power usage and is one of the advantages of the Wayland
protocol.  If people come to us complaining that "you can't do that in
Wayland" just because GNOME or KWin aren't doing it, we can point to Weston
and say, "See, yes you can, they just aren't".  Another fantastic example
of this is the way the RPi backend uses planes.  So I think showing off
performance things we can do thanks to Wayland is important, squeezing out
clock cycles isn't.

>
> > - 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 what we want here is "easily forkable".  Not that we want people to
be trying to "fork the project" but that we want to make it easy for
someone to work on a feature branch in their own github repo and make
things easy to merge back in or rebase on upstream.  What does an "easily
forkable" project look like?  That's a good question.

First would be to encourage people to work in feature branches rather than
have to have everything on the list and/or in Weston core.  While I think
most things may want to be upstream eventually, trying to do upstream
everything as you go is hard when people are trying to use it as a test-bed
and you're trying to do stable release at the same time.  We may even want
to allow stuff to go upstream by merges rather then everything as a linear
series on the ML.

Another thing might be to make things structured a little better to try and
structure things in a more compartmentalized model.  Right now, Weston has
a lot of files that are thousands of lines and should probably be broken up
a bit (I'm looking at you, compositor.c).  Having things structured a
little better may make it easier for people to rebase.  That said,
restructuring is a lot of churn and makes it hard to rebase, so that has to
be taken into account too.

> > 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.
>

Yes please!  One thing that has always bothered me is the existance of a
"weston community" of people trying to make Weston the DE happen.  I think
that the Wayland world will need a place for the lightweight desktop such
as icewm and i3 are for X and maybe Weston is the place to do that.
However, I think that users and potential future developers should be
encouraged to try and help one of the other major DE's get their Wayland
implementations off the ground.  The other thing the Wayland-specific
community can do is, as Bryce mentioned, develop tools and test suites to
help implementers.

There's one big caveat to what I just said that I think is worth
mentioning.  Namely, that making libraries and things for DE's to use is
something that needs to be guided by DE development itself.  You can't
really start a helper project without someone who's familiar with big DE's
and what they need.  That said, I'm sure libinput wouldn't mind a little
help and maybe other library projects will spring up.

The other area (that Bryce mentioned in a different area) is tools.
Protocol dumpers are great.  Other things that allow for better
introspection or make it easier to implement the protocol would be
fantastic.

>
>
> > 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.
>

Kristian couldn't do it alone forever either.  Why do you think you're
doing it. :-P  For a while, I was trying to keep somewhat on top of things,
but I don't have much time for it these days.

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.

If your managers at Samsung are ok with it, that would be fantastic!  If
nothing else, making sure things get reviewed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20141209/c7f27c70/attachment-0001.html>