Jim White wrote:
The whole "quality" and "hack" language is a red herring. To see that it is selective and subjective, just look at the code, try xrender.c for example.
The difference is that presumably the person who submitted that code demonstrated that they understood the problem that they were trying to solve and convinced Alexandre that fixing it without hacks would lead to other problems or take months to code.
At least one person has mentioned that there is no "right of appeal", but there is - you can reply to Alexandre's rejection comment by doing the above.
Another way of demonstrating that you understand the problem is to demonstrate that you understand the code by submitting patches to it, fixing smaller and easier to solve bugs.
Steven cited the business at Wineconf of Alexandre never being "proved wrong on a technical matter". Another straw man. The part of Alexandre's patch process that is the root of this conflict between Wine development-focused developers vs. Wine user-focused developers is that which consists of style and aesthetic considerations. CodeWeavers Wine version is full of patches that Alexandre won't accept for WineHQ. Obvious proof that the Alexandre's policy isn't the only way to make a Wine that people value. In fact it proves that the WineHQ's patch process is not good enough to make Wine that people will pay for, while CodeWeavers' is.
I'm not sure I understand what point you are trying to make here. We at CodeWeavers have to retest each hack before each release to make sure that it still works and whether it is still necessary. We have a set of applications that we guarantee to support for each release, whereas there are no such requirements for a WineHQ release. This happens because we want to reduce the number of conflicts when we merge from WineHQ, but people probably wouldn't do this in Wine, since we generally only hear from users of certain applications when the applications don't work.
-- Rob Shearman
