Hello Robert,<br><br>I am an employee of CodeWeavers and one of the former project coordinators of the ReactOS Project though my views do not represent either the position of my employer or the ReactOS Project of which I am no longer actively affiliated.
<br><br>This thread was part of the reason I wanted to chair the governance discussion at Wineconf so please don't think your point of view and others are not considered. The question about governance has come up from time to time in regard to several issues such as design decisions, development methods and general patch submission processes. These issues collectively have made me interested in the overall topic of governance and seeing if there is a way we can streamline and or broaden the process.
<br><br><div><span class="gmail_quote">On 9/22/06, <b class="gmail_sendername">Robert Lunnon</b> <<a href="mailto:bobl@optushome.com.au">bobl@optushome.com.au</a>> wrote:</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
1. Publish the patch acceptance policy - Make sure this is the acceptance<br>policy and not the patch acceptance process. The Patch acceptance policy<br>should be developed by community process and be subject to change (and change
<br>control). Perhaps a standing wineconf agenda item here.</blockquote><div><br>I think we all have agreed that Alexandre's rules for patch acceptance should be more broadly stated on the website or wiki, as well as have a system for first time contributors to be made aware of the rules and be mentored on how to become a good Wine contributor. It has always bothered me, the thought that someone might be submitting a patch for the first time, only to have that patch go to the void for whatever reason and be turned off to the project. For all we know that new developer might have turned out to be a very active member of the project. It is my hope that the new ambassador system we have proposed will help with this situation of getting new developers up to speed and get more new patches in to the tree quicker. In regards to making it a standing item, it already defacto is as we have had a discussion about the process in one form or another every year. I am happy to keep trying to tweak the process in the future.
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">2. Adapt the patch acceptance process to create a right of appeal where a<br>patch can be proven to be within the Patch Acceptance policy. Appeal should
<br>be independent of and binding on Alexandre - this eliminates one-to-one<br>arguments about patch acceptability while still providing good excellent<br>control. It will also have the effect of reducing Alexandres workload.
</blockquote><div><br>I jokingly referred to the discussion as the "off with his head" meeting at Wineconf however we all came to the conclusion this was unneeded. It was in fact Jeremy White that proposed having some sort of democratic system to override Alexandre if we thought he was making some sort of mistake. It was at this point I asked him and every other developer in the room to name one time Julliard has been wrong on a technical issue. There are plenty of areas of disagreement on the patch submission process and even some disagreements on design decisions from time to time however even when there are disagreements on design, it has never been shown to me where the situation comes does to Julliard being wrong and someone else being right. If you can show a pattern of patches rejected that clearly should have been merged then I might agree with you and the rest of the Wine developers would also be chanting "off with his head". As far as I understand the problem with your Solaris patches recently, your had quite a large number of invasive changes that were able to be corrected with some minor tweaking of compiler flags. Clearly this is a disagreement on design rather than the merits of the patches. If Alexandre were to ever develop a pattern of rejecting technically sound patches for no damn good reason I assure you we would revisit this discussion. As it stands right now the only reason technically good patches have been rejected is due to concerns over reverse engineering in another project.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">2. Have a Wine Developers - Bill of rights - particularly preserve the right<br>
to dissent and disagree. To develop freely, most importantly It must<br>recognise, as Dr Gow has so eloquently said, that most Wine developers don't<br>have any interest in WIne and must be treated as valuable volunteers. This
<br>has to be respected in the Bill of Rights.</blockquote><div><br>The developers have the right to disagree and we do quite often. However we have mob rule with a benevolent despot and none of us really like to work any other way. If the project demographics change and the developers decide they don't like the system then, once again, we would change. Our governance is ultimately that Alexandre rules at the consent of the governed and while it can suck to be in the minority of mob rule from time to time, the mob agrees to keep Alexandre as the benevolent dictator for life. I for one hope this never changes as it seems to be the best system for making stable FOSS software. I've been in projects that had full access to everyone to the tree and seen the types of problems that result from development anarchy. The Wine model is the best for a project of our size.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">3. Have a community process for properly handling process change.</blockquote>
<div><br>The process is whatever works best of Alexandre. See above. The trick is finding ways to make him more effective and helping the community to be more effective with him. His acceptance policies are his to decide as he pleases as long as the mob has not overthrown him in armed revolution.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">4. Have a similar wine users Bill of rights - The users of wine need a say.</blockquote>
<div><br>They do have a say in terms of contribution of time for testing, bug hunting, donations, supporting companies and projects built around Wine, etc. As a Wine developer I do not develop for the users. I develop for my own needs and really don't care what the users have to say other than how it relates to my job. I know it sounds cold but I am going to work on what I am interested in when donating my time to Wine. Forcing the FOSS developer to be beholden to the even greater mob of users is not the answer.
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">5. Have a community process for handling these requests according to the BOR.<br></blockquote>
</div><br>By being an active developer, you are a member of the community and well within your rights to bring these matters up on wine-devel as you have done or discussing them at Wineconf however if Alexandre disagrees he disagrees. We have decided to keep the current system of governance and that does not include a veto of him.
<br clear="all"><br>The idea of Dr. Gow in having a totally open forked Wine tree sounds interesting but having gone through the X11 ReWind fork I do not believe this will help the project. In fact I believe it would stagnate it and waste the time of anyone working on such a fork. You would still need someone to merge and manage conflicts when syncing to winehq which would require a doppelganger clone of Julliard. I don't know of anyone else that thinks the current process sucks enough, has the experience needed to do the syncing on a daily basis and is even 1/10th as capable as Julliard when it comes to the internals of Wine design.
<br><br>-- <br>Steven Edwards<br><br>"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo