Alexandre said ========================================= To be honest, I have no idea what it is that you are suggesting. All I see is phrases like "community focused process" or "acceptance policy" which frankly are just meaningless buzzwords. If you expect anything to happen, you'll need to make much more concrete suggestions, and provide examples to make us understand how what you are suggesting would work in practice, and how it would be different from what we are doing now. -- Alexandre Julliard julliard(a)winehq.org ========================================== To which I said I would respond soon - well here goes. From the outset I want to say that I am not going to redefine the wine project or make suggestions in the sense of a particular change. I want the communities of developers users and others to define that change. What I will do here is suggest ways in which we could organise to make a change as a collective. Firstly the buzzwords "Community Focused Process" means what it says, develop a process which is centred on the community the project serves. This requires the project to answer some introspective questions 1. Who "owns" Wine, does wine belong to A.) Alexandre, or B) the community it serves. 2 If the answer is B then which community. It may surprise some to realise that a project like this has many communities. We discovered this when setting up the OpenSolaris community process. Some obvious ones are "The Developer Community" and "The User Community" and "Developer + User" Community. There are other less obvious communities, eg the community of distribution maintainers who may be neither developer or user. If we decide that the community "Owns" Wine then it needs to be established whether the community has a right to direct wine's development. As the "Owner" I'd argue the community should have this right. Second Buzzword "Patch Acceptance Policy" means the rules by which a patch is deemed acceptable or not. At the moment this is pretty close to "It's acceptable if Alexandre commits it" This is OK in a community process as long as the community that wine serves supports this approach. I think the recent thread throws significant doubt on this. This particular patch acceptance policy is not Transparent, this is the key reason why dropped patches cause so much argument, why many developers leave the project and possibly why Wine doesn't get the major backing some projects do (EG Gnome, KDE Xorg) dealing with the wine project is risky business. Now what do I propose... 1. Answer the questions about the "ownership" of wine and identify the community it serves. Determine the right of the community to be involved is setting wines direction IE The Bill of rights I mentioned before (for each community Developers VS Users etc). 2. Alexandre documents the exact logic he uses to determine patch acceptability which becomes the patch acceptance policy in the interim. This should be done to the point that someone else could take over from Alexandre and achieve the same result. This opens the way to multiple maintainers as well as allowing Alexandre to take more holidays. 3. The project develops a community process for establishing project direction and maintaining the patch acceptance policy which includes stakeholders elected from the "owners" IE communities with a stakeholding in wine 4. A community process is run to A.) Establish the communities objective for wine - this will actually probably be reasonably argumentative, but that is exactly how it should be. If it's not there is probably something wrong. It was with OpenSolaris and governance was the greatest concern with that project too. B) review the Patch acceptance policy in line with the community objective. For example the policy may be adjusted to favour functionality improvements, or loosen gating on changes leading to solutions that wine critically needs or even establish a "must have" application. 5. A mechanism is created to independently review patches (appeal process) for acceptability IE Whether a patch meets the acceptance policy. Note that if a patch acceptable to the policy is rejected then the policy may need to change (Requiring a new community process to review that change) or an architectural decision needs to be taken. This is done by the architecture review board in the OpenSolaris process. Among other things when a patch is sent to appeal the owner of the patch is guaranteed an explanation of how the patch doesn't meet the acceptance policy. Now if we did all this we would * Have a picture of the needs of the community * Have a way to direct the project toward meeting that need * Have a way to demonstrate we intend to meet that need * Have a consistent review process for patches * Have a way to multistream patches * Have an open transparent, trusting and consistent environment in which to work * Have a way to change and grow * Open ways to allow business to confidently invest in Wine. Even if we ended up with exactly what we have now we will have improved transparency resulting in higher quality of work and less resentment of the process, improving developer retention rates and reducing disputes. Bob
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robert Lunnon wrote: arrgh, I know you're not supposed to feed the trolls, but... I'm a user I find wine to be very useful. I've got a client who owns a bus charter line that was able to move away from windows, and the only thing they needed was their payroll system that does work in wine. the way I see it, wine is distributed under the LGPL. this means that when I download it, I 'own' it, am able to 'direct' it's 'development', etc. --privately-- what I don't have the right to is to tell anyone on earth what to do. that includes Alexandre, Rob, or anyone else. if anyone else is interested in modifications I may happen to make (I don't have any, wine just works for me), that's great, but I can't force anyone to listen to me. perhaps this email is futile too. - --RFMuller -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFFG8dNjfMdLxNd9ZERAg/mAJ9ADty2vUAzecP2dxc8tQ4TdSbOSgCfUbMs tuN8smer6kYFr2LFSqaMAEc= =vOgw -----END PGP SIGNATURE-----
2. Alexandre documents the exact logic he uses to determine patch acceptability which becomes the patch acceptance policy in the interim. This should be done to the point that someone else could take over from Alexandre and achieve the same result. This opens the way to multiple maintainers as well as allowing Alexandre to take more holidays.
I'm of the opinion that code is "art" as its implementation is subjective. The idea that you could document when a patch is acceptable or not seems like an impossibility. You might be able to set a series of ground rules, no c++ comments, shouldn't contain asm unless necessary, but even a patch that fits these requirements isn't necessarily an acceptable patch. I've almost never been unhappy with AJ's judgement except in cases like the safedisc patches where it seemed like no one really knew what was "good" and more effort wasn't put into at least providing development guidance. Chris
On Thu, September 28, 2006 9:24 am, Chris Morgan wrote:
I'm of the opinion that code is "art" as its implementation is subjective. The idea that you could document when a patch is acceptable or not seems like an impossibility.
I wholeheartedly subscribe to this. We are far away (as a profession) to document what is a good/bad patch even when that is fairly obvious to a good maintainer, let alone document exactly the thought process for more complicated cases. This is a waste of time. Alexandre is an amazing judge of patches, we should be happy we have him. More to the point, I think this is missing the point. If we are good at something, it is in evaluating patches on their techincal merit. This doesn't need improvement. What we may be erring a bit is putting the techincal aspects above and beyond other considerations, such as desire for a feature at the expense of a little quality. We are delaying patch inclusion waiting for the 'right' solution, which in part is good, but when that means keeping desired features away for years on end, i think it hurts us more than it helps us being relevant to our users. Maybe there's a way to help Alexandre better understand how much people want something, maybe that can be factored in a bit? -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.
On 9/28/06, Chris Morgan <chmorgan(a)gmail.com> wrote:
I've almost never been unhappy with AJ's judgement except in cases like the safedisc patches where it seemed like no one really knew what was "good" and more effort wasn't put into at least providing development guidance.
http://www.winehq.org/pipermail/wine-devel/2006-August/050489.html Tom
Chris
Robert Lunnon wrote:
"Community Focused Process" means what it says, develop a process which is centred on the community the project serves. This requires the project to answer some introspective questions
1. Who "owns" Wine, does wine belong to A.) Alexandre, or B) the community it serves.
A) Alexandre is a benelovent dictator. He manages Wine with the interests of "the community" in mind, as he sees them.
1. Answer the questions about the "ownership" of wine and identify the community it serves. Determine the right of the community to be involved is setting wines direction IE The Bill of rights I mentioned before (for each community Developers VS Users etc).
Your "bill of rights" is the Wine license, the LGPL.
2. Alexandre documents the exact logic he uses to determine patch acceptability which becomes the patch acceptance policy in the interim.
It's very likely impossible to write that down. If you don't agree with me, please write down your proposal.
3. The project develops a community process for establishing project direction and maintaining the patch acceptance policy which includes stakeholders elected from the "owners" IE communities with a stakeholding in wine
NetBSD is a project that is (was?) run by committees: http://mail-index.netbsd.org/netbsd-users/2006/08/30/0016.html If you want Wine to be run by a committee, how about creating your own fork so you can run it as you see fit? Mike
participants (6)
-
Chris Morgan -
Dimi Paun -
Mike McCormack -
Robert Lunnon -
Robert Muller -
Tom Wickline