Where should project Weston go?

[Bryce Harrington]

On Tue, Dec 09, 2014 at 11:36:42AM -0800, Jason Ekstrand wrote:
> 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:
> 
> > 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.

Right.  So perhaps:  "Demonstrate performance characteristics of Wayland."

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

Many projects also get good mileage out of plugin systems, where
experimentation can be done outside the core.  Some plugins can be
pulled into core once they're ready; others will remain on the fringe.

The trick seems to be to provide the community with some sort of
mechanism that allows convenient distribution of unofficial plugins
outside the official release process.

The other trick is providing a really good plugin API...

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

Nice thing about tools is they can be distributed separately, so can be
handled in their own repository.

Diagnostic tools might be useful as well; particular if they work
cross-compositor.

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

They're quite ok with it, it's in fact part of our team's charter to
help upstreams with maintenance work, and Wayland's high on Samsung's
priority list.

Bryce