On Wed, Apr 17, 2013 at 1:34 PM, Kristian Høgsberg <[email protected]> wrote: > Hello list,
Hey Kristian. Thanks for taking the time to start this discussion. I'm probably not all that qualified to make a comment here, but I will point out some ideas and observations I've had about this. > I see more reviews on the list now and I really appreciate that; > thanks to Thiago for writing the email and to everybody who has jumped > in and reviewed patches. However, Pekka brought up a good point: > > "Anyone can review coding style, but what if we massage coding > style and other minor details back and forth a lot, and then > someone does a proper subjective review NAK'ing the whole idea, or > at least forcing a complete rewrite. Is that review and > improvement work wasted for nothing, or is it useful?" 1. Patch review: Pre-commit code review is a good development practice, but it needs to have a quick turnaround time for contributors to feel engaged in the process. I don't think there is a real problem with the patches-on-the-mailing-list approach, though I might suggest moving the project version control to a platform like GitHub where things like pull requests make managing the queue easier for both contributors and reviewers. I can make the case for this more generally if people are interested, but I won't talk about it too much now. Something that I think should be put in the "guidelines" is a preference for RFCs where functionality changes are being proposed. Then we can first review the proposed changed specification, see if the maintainers are happy with it, commit that to a specifications/ subdirectory in-tree and then work on implementing that specification in a second review process. > Part of the confusion around this is that weston started out as just a > way to verify the protocol as well as gbm, KMS, evdev etc integration, > which implies that it's throw-away code or at best a source for copy > and paste. On the other end of the scale, what weston is today is > obviously a lot more than just sample code, we even have a toy desktop > that makes it look like it's a real desktop environment. > > In my mind, the main output of weston is the core compositor and the > plug-in API. We have a very efficient GLES2 renderer, very good KMS > integration and overlay usage, and a good input stack. We have good > infrastructure for writing custom backends and a flexible way to > plug-in a higher-level shell component to handle window-manager-like > responsiblities. This is the part of weston I consider product > quality and we have to maintain high standards when working in that > area - strict error checking, handle all corner cases etc. The core > compositors goal is to be a base for other projects, similar to how > the X server isn't a full desktop environment or mobile/embedded UI, > but a core technology to build one upon. It is also still the > reference implementation and must implement and exercise all core > protocol. 2. Re-use of weston functionality Weston has a lot of really great functionality that would be useful to lots of different desktops. I'm thinking about some of the core-stuff like geometry / texture clipping, opaque region calculation, video capture, damage handling, gbm etc. This stuff is really hard to get right, and its a big ask for people to deliver new shells on top of the wayland protocol when they have to get all the groundwork right first. Also, the main goals of renderers and display managers don't really differ at that much, you just want to get it a) right and b) fast. To that end, encouraging code sharing makes a lot of sense. What I would suggest is that instead of a plugin model, weston-as-a-library might make more sense. That would mean that lots of the compositing / display handling logic can be put inside of a libweston for other compositors to build a window manager and shell on top of. This is basically how mutter works today (eg, libmutter). It also means that for those projects, testing becomes a lot easier. Testing a shell plugin is really hard to do because of the extra dependency on the host binary, whereas desktop environments that wish to test their window management and other logic can simply isloate the weston library. This proposal is a little tricky considering the implicit global context. I would suggest at least that weston-as-a-library is not responsible for making any OpenGL calls, but rather provides a set of utility functions so that implementing compositors can do those calls themselves. The other alternative is to ask that desktop environments build on top of weston as a shell plugin, though I suspect that could be a controversial proposal. Best Regards, Sam -- Sam Spilsbury _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
