Hello list, A few weeks ago, Thiago Maciera sent out a good email about patch review and how everybody can help with the review effort:
http://lists.freedesktop.org/archives/wayland-devel/2013-March/008174.html 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?" Fortunately a lot of patches are easy to review and accept - bug fixes or fleshing out FIXMEs or a self-contained new backend for example. Patches that add features or change established behavior are typically less obvious and in those cases it's of course good to first try to determine whether the overall idea is right. To that end, I'd like to see if we can all agree on the scope of weston. 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. The desktop shell in weston serves three goals: to validate wl_shell protocol, to make weston do something useful when you start it up, and to provide a reference for how to implement a shell module. The desktop shell is not supposed to be a generally useful desktop environment. When we're implementing something for the weston desktop shell, we go for simplicity and protocol coverage rather than full configurability or external dependencies. As for xwayland, I'd like this module to be better quality and provide easy integration of X applications for UIs that build on weston. As it is, it's rather spotty in its support for ICCCM and EWMH though, and mainly serves as a validation effort for X integration. Tell me what you think, Kristian _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
