A barebone version of Weston?

[Christopher James Halse Rogers]

On Tue, 2012-07-10 at 18:53 -0700, Mikalai Kisialiou wrote:
> There is an article on http://www.phoronix.com that there is a new
> feature of sliding desktop support in Weston. I am wondering if it
> would make sense to split Weston implemention into 2 distinct ones: a
> barebone implementation with minimal features (architecture + driver
> compatibility) and a full-featured version?
>  
> I am not saying that the sliding desktop is somehow a bad idea (it is
> a great idea). I do love this feature and will definitely like to see
> it on my desktop. My concern, however, is slightly different: 
>  
> Some people may look at potential opportunities to implement their own
> version of a Wayland-compliant server. These people will likely be
> from different areas and seek some kind of a "Hello world" version of
> a Wayland compliant server. The applications may range from low-power
> portable devices with limited performance to powerful CAD
> workstations stacking dual graphics card firepower. Because
> the requirements and expectations for the graphics interface on
> such systems are vastly different, I am afraid that a W-server that
> aims to be one-size-fits-all may end up being one-size-fits-none. As
> optional features start propagating into Weston it will grow
> into something similar to another X-server, and we are going to be
> back to square 1.
>  
> I understand that there will be some overhead involved for developers
> to maintain 2 branches. However, most features will probably not fall
> into the barebone version, so the commits for new cool features would
> still be limited to 1 branch only. Bug fixes will indeed be harder to
> commit. Can the 2nd full-featured branch be a library on top of the
> barebone architectural version?
>  
> Also, is there some sort of a policy or a decision making process as
> to what gets committed into Weston? What do the main developers think
> about 2 branches? I just thought I'd raise these concerns before a
> whole list of optional features gets committed into Weston. 

As long as it's restricted to the shells and anything under clients/ I
don't think it matters how much functionality is folded into weston.
Indeed, it's probably valuable, as it helps ensure the core weston &
wayland code can support such use.

Eventually it might become sufficiently big to do a source split, but
that seems a way off.

I agree that there needs to be a higher bar than “chuck it in” for
commits touching the core weston compositor, but I don't think I've seen
any commits overstepping reasonable bounds there.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20120711/af8a276e/attachment-0016.pgp>