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.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel