I note the recent flamefest, where some of this list seared yet another contributor (Roland Kaeser)
Since this particular very old, very shrivelled chestnut. is one of my personal favourites (thanks to Colin Wright for the chestnut thing...). I'd like to repeat my observations about this. Feel free to flame away since I have donned my asbestos suit and have long since decided my viewpoint.
The problem is that code gets rejected that is *** NOT *** Hacky because there is a, single point of review - a single opinion of what constitutes a hack, and no appeal process. For example I once submitted code to implement cpu.c using the x86 cpuid instruction directly on all x86 platforms. This was NO hack. But the code was rejected. This code replaces the OS specific code for several x86 cases with generic code. The way I see it this code removes hacks (since I consider any OS specific code fragment a hack). This just shows that opinions differ about what a hack is. This code now sits in my patch-kit, never to see the light of day on wine-hq, but happily runs in every copy of wine for Solaris for the last 4 years with ZERO issues.
No hacks should not be an objective, by my definition wine already has more hacks than just about any other open source package out there. Linuxisms continue to contaminate wine every month (I can vouch for it). What we need is management, balance between function and beauty delivered by peer review. Necessary functional hacks should be allowed unless they have severe side-effects. Even application specific work-arounds can be permitted if the work around adds significant functionality per the objectives of the project, the scope of the work-around is suitably confined, and assuming the code can be maintained over time.
Wine needs process...
The issue is not code, It's governance. Governance to establish balance, balance between beauty and function.
Bob
On Sunday 17 September 2006 00:09, you wrote:
I note the recent flamefest, where some of this list seared yet another contributor (Roland Kaeser)
You might have noticed that none of the core contributers commented on this, because they're all at WineConf right now. Just chill, I think there'll be a couple of suggestions once we get back. E.g. that "deadline" for 1.0 has been talked about already. Just let us finish WineConf and get some writeup on this done.
Cheers, Kai
On Sun, Sep 17, 2006 at 08:09:24AM +1000, Robert Lunnon wrote:
I note the recent flamefest, where some of this list seared yet another contributor (Roland Kaeser)
Since this particular very old, very shrivelled chestnut. is one of my personal favourites (thanks to Colin Wright for the chestnut thing...). I'd like to repeat my observations about this. Feel free to flame away since I have donned my asbestos suit and have long since decided my viewpoint.
The problem is that code gets rejected that is *** NOT *** Hacky because there is a, single point of review - a single opinion of what constitutes a hack, and no appeal process. For example I once submitted code to implement cpu.c using the x86 cpuid instruction directly on all x86 platforms. This was NO hack. But the code was rejected. This code replaces the OS specific code for several x86 cases with generic code. The way I see it this code removes hacks (since I consider any OS specific code fragment a hack). This just shows that opinions differ about what a hack is. This code now sits in my patch-kit, never to see the light of day on wine-hq, but happily runs in every copy of wine for Solaris for the last 4 years with ZERO issues.
Well, regular WINE no longer needs this patch, since it has been fixed differently.
In fact according to Alexandre everyone of your patches is now done in mainline, so your patch set is no longer necessary.
No hacks should not be an objective, by my definition wine already has more hacks than just about any other open source package out there. Linuxisms continue to contaminate wine every month (I can vouch for it). What we need is management, balance between function and beauty delivered by peer review. Necessary functional hacks should be allowed unless they have severe side-effects. Even application specific work-arounds can be permitted if the work around adds significant functionality per the objectives of the project, the scope of the work-around is suitably confined, and assuming the code can be maintained over time.
Wine needs process...
Wine works fine as-is in my opinion ;)
Ciao, Marcus
On Sunday 17 September 2006 21:48, Marcus Meissner wrote:
On Sun, Sep 17, 2006 at 08:09:24AM +1000, Robert Lunnon wrote:
I note the recent flamefest, where some of this list seared yet another contributor (Roland Kaeser)
Since this particular very old, very shrivelled chestnut. is one of my personal favourites (thanks to Colin Wright for the chestnut thing...). I'd like to repeat my observations about this. Feel free to flame away since I have donned my asbestos suit and have long since decided my viewpoint.
The problem is that code gets rejected that is *** NOT *** Hacky because there is a, single point of review - a single opinion of what constitutes a hack, and no appeal process. For example I once submitted code to implement cpu.c using the x86 cpuid instruction directly on all x86 platforms. This was NO hack. But the code was rejected. This code replaces the OS specific code for several x86 cases with generic code. The way I see it this code removes hacks (since I consider any OS specific code fragment a hack). This just shows that opinions differ about what a hack is. This code now sits in my patch-kit, never to see the light of day on wine-hq, but happily runs in every copy of wine for Solaris for the last 4 years with ZERO issues.
Well, regular WINE no longer needs this patch, since it has been fixed differently.
In fact according to Alexandre everyone of your patches is now done in mainline, so your patch set is no longer necessary.
No hacks should not be an objective, by my definition wine already has more hacks than just about any other open source package out there. Linuxisms continue to contaminate wine every month (I can vouch for it). What we need is management, balance between function and beauty delivered by peer review. Necessary functional hacks should be allowed unless they have severe side-effects. Even application specific work-arounds can be permitted if the work around adds significant functionality per the objectives of the project, the scope of the work-around is suitably confined, and assuming the code can be maintained over time.
Wine needs process...
Wine works fine as-is in my opinion ;)
Which you are entitled to, but my opinion happens to differ. Whether the wine core source has all the patches, (Which it doesn't - many, but not all) isn't relevant, it's the process that they go through that I believe could improve.
Bob
Wine works fine as-is in my opinion ;)
Which you are entitled to, but my opinion happens to differ. Whether the wine core source has all the patches, (Which it doesn't - many, but not all) isn't relevant, it's the process that they go through that I believe could improve.
For the record, Governance is something we often spend a chunk of time on at each Wine conference.
Brian has written a nice summary of Wineconf on WWN (thanks Brian!), including a reprise of the talk on governance.
Being insufferably long winded, and feeling the need to create a complete record, I would add a few things to what Brian wrote.
First, I think there was clear and essentially unanimous agreement that the current high standards for quality were a Good Thing (TM), including the Holy Order of Writing Conformance Tests.
Second, I think we had fairly clear agreement that so long as he can handle it, it is most efficient to have Alexandre as the sole maintainer. Obviously, the more help he gets from component maintainers (e.g. Mike/MSI, Rob/COM), the better.
Third, I think there was clear agreement that Alexandre is often a Royal Pain In the Ass (RPITA). He ignores patches, responds tersely, and sometimes delivers the occassional kiss of death: "I can't tell you what to change, but your patch is wrong."
However, we, the assembled 30 or so of the most core Wine developers, could not think of a single case where Alexandre had been proven wrong. Nor could we think of a single instance when he had failed to be persuaded by reasonable argument; making a rather compelling case that he is generally right.
We also talk, from time to time, about building some sort of patch tracking system to allow for better management of patches. Something like a 'ticket' system, so people could see the status of their email, whether or not it had been reviewed, etc, etc. I think there is some sense that this might be useful, but it's a sufficiently complex problem, and it has to be written in emacs, that we always defer it for the future.
So I think the strong (if not unamimous) consensus was to continue on as we are, but make an effort to provide an 'ambassador' program of some kind, particularly around folks that are new to Wine.
If you have a specific concrete suggestion for change, this would be a fine time to put it forward.
But if your proposal is largely: "Alexandre should accept more patches", I think you'll find that none of the core Wine developers will support you in that, so it's not worth the effort, at least not in this venue.
Cheers,
Jeremy
Some kinda patch management system would help. I think like bugzilla.
On 9/20/06, Jeremy White jwhite@winehq.org wrote:
Wine works fine as-is in my opinion ;)
Which you are entitled to, but my opinion happens to differ. Whether the wine core source has all the patches, (Which it doesn't - many, but not all) isn't relevant, it's the process that they go through that I believe could improve.
For the record, Governance is something we often spend a chunk of time on at each Wine conference.
Brian has written a nice summary of Wineconf on WWN (thanks Brian!), including a reprise of the talk on governance.
Being insufferably long winded, and feeling the need to create a complete record, I would add a few things to what Brian wrote.
First, I think there was clear and essentially unanimous agreement that the current high standards for quality were a Good Thing (TM), including the Holy Order of Writing Conformance Tests.
Second, I think we had fairly clear agreement that so long as he can handle it, it is most efficient to have Alexandre as the sole maintainer. Obviously, the more help he gets from component maintainers (e.g. Mike/MSI, Rob/COM), the better.
Third, I think there was clear agreement that Alexandre is often a Royal Pain In the Ass (RPITA). He ignores patches, responds tersely, and sometimes delivers the occassional kiss of death: "I can't tell you what to change, but your patch is wrong."
However, we, the assembled 30 or so of the most core Wine developers, could not think of a single case where Alexandre had been proven wrong. Nor could we think of a single instance when he had failed to be persuaded by reasonable argument; making a rather compelling case that he is generally right.
We also talk, from time to time, about building some sort of patch tracking system to allow for better management of patches. Something like a 'ticket' system, so people could see the status of their email, whether or not it had been reviewed, etc, etc. I think there is some sense that this might be useful, but it's a sufficiently complex problem, and it has to be written in emacs, that we always defer it for the future.
So I think the strong (if not unamimous) consensus was to continue on as we are, but make an effort to provide an 'ambassador' program of some kind, particularly around folks that are new to Wine.
If you have a specific concrete suggestion for change, this would be a fine time to put it forward.
But if your proposal is largely: "Alexandre should accept more patches", I think you'll find that none of the core Wine developers will support you in that, so it's not worth the effort, at least not in this venue.
Cheers,
Jeremy
On 9/20/06, Vijay Kiran Kamuju infyquest@gmail.com wrote:
Some kinda patch management system would help. I think like bugzilla.
It'd better have an emacs interface ;)
-Brian
After having followed this thread for some time, I feel that there is an aspect that is often missed in the debate.
As I see it, it would appear that Wine contributors fall into essentially two camps. There are those who develop Wine for Wine's sake. This category includes the core developers, and others who just feel strongly about a particular aspect in order to improve it and perfect it. These people have time to spend developing and perfecting their code to meet the necessary high standards for acceptance and would not see the current system of governance to be an issue. These are the very people that would attend Wineconf and discuss the issue!
There is another category, however, and I suspect it is the larger of the two. Some people simply need to quickly fix an aspect of Wine in order simply to get an application working. These individuals, a category into which I fall, are driven by a very different motive. To take an example, my (very) small contribution to Wine was driven by the need to get a commercial ECAD application running, so that I could continue to use the application as a production tool on a production system in order to continue to function as an electronics engineer. In my case, I am also a software developer who believes in feeding useful fixes back to the community, so I used up some of my valuable free time and got the patch accepted. It took approximately three times longer to get the patch accepted than it did to fix the problem in the first place!
I persevered, but I wonder how many other individuals who fall into this category would do the same? Another contractor driven purely by commercial pressures may have just got it working and kept the fix in their own tree. Such people do not have the free time or the inclination to go through the numerous iterations to get the patch accepted. Free time is a rare commodity these days, and most software developers will have other projects. These are not the people who would attend Wineconf and whose opinions can only be solicited through other means. How many Wine trees are there out there containing useful small fixes that see the light of day outside of the developers's box, simply because they do not have the time to struggle through the QA system. A number of these patches could be being lost to the community.
How to capture these 'lost' contributions is a difficult issue. Maybe a centralized repository for patches could be maintained separate from the main Wine tree and with a very loose method of acceptance (maybe just ensure that it is clearly indicated what the patch is for and what version it can be applied to). This way it would be very easy for a contributor to place a patch somewhere where it is easily accessed by the community. A developer with more time who is interested in it may pick it up and clean it up for inclusion in the tree, but at least the patch is available for others to use, saving re-invention of the wheel.
The quality of Wine is important, and a workable QA system is very necessary. However there should be a mechanism to enable widespread dissemination of contributions that for various reasons do not merit direct inclusion in the tree at that time and for which the developer has neither the time nor the inclination to do battle with the QA system.
Just my thoughts.
John. Vijay Kiran Kamuju wrote:
Some kinda patch management system would help. I think like bugzilla.
On 9/20/06, Jeremy White jwhite@winehq.org wrote:
Wine works fine as-is in my opinion ;)
Which you are entitled to, but my opinion happens to differ.
Whether the wine
core source has all the patches, (Which it doesn't - many, but not
all) isn't
relevant, it's the process that they go through that I believe could
improve.
For the record, Governance is something we often spend a chunk of time on at each Wine conference.
Brian has written a nice summary of Wineconf on WWN (thanks Brian!), including a reprise of the talk on governance.
Being insufferably long winded, and feeling the need to create a complete record, I would add a few things to what Brian wrote.
First, I think there was clear and essentially unanimous agreement that the current high standards for quality were a Good Thing (TM), including the Holy Order of Writing Conformance Tests.
Second, I think we had fairly clear agreement that so long as he can handle it, it is most efficient to have Alexandre as the sole maintainer. Obviously, the more help he gets from component maintainers (e.g. Mike/MSI, Rob/COM), the better.
Third, I think there was clear agreement that Alexandre is often a Royal Pain In the Ass (RPITA). He ignores patches, responds tersely, and sometimes delivers the occassional kiss of death: "I can't tell you what to change, but your patch is wrong."
However, we, the assembled 30 or so of the most core Wine developers, could not think of a single case where Alexandre had been proven wrong. Nor could we think of a single instance when he had failed to be persuaded by reasonable argument; making a rather compelling case that he is generally right.
We also talk, from time to time, about building some sort of patch tracking system to allow for better management of patches. Something like a 'ticket' system, so people could see the status of their email, whether or not it had been reviewed, etc, etc. I think there is some sense that this might be useful, but it's a sufficiently complex problem, and it has to be written in emacs, that we always defer it for the future.
So I think the strong (if not unamimous) consensus was to continue on as we are, but make an effort to provide an 'ambassador' program of some kind, particularly around folks that are new to Wine.
If you have a specific concrete suggestion for change, this would be a fine time to put it forward.
But if your proposal is largely: "Alexandre should accept more patches", I think you'll find that none of the core Wine developers will support you in that, so it's not worth the effort, at least not in this venue.
Cheers,
Jeremy
Dr J A Gow wrote:
How to capture these 'lost' contributions is a difficult issue. Maybe a centralized repository for patches could be maintained separate from the main Wine tree and with a very loose method of acceptance (maybe just ensure that it is clearly indicated what the patch is for and what version it can be applied to). This way it would be very easy for a contributor to place a patch somewhere where it is easily accessed by the community. A developer with more time who is interested in it may pick it up and clean it up for inclusion in the tree, but at least the patch is available for others to use, saving re-invention of the wheel.
Why reinvent the wheel? If such people can spend their time chasing down the problem and developing a fix for it, they sure can open a bug in bugzilla, describe theproblem and attach a patch they made. How more simple can it be?
No patches lost, no extra places to look for. And all the information describing the problem. Everything in one place.
Vitaliy
Hi,
On Wed, Sep 20, 2006 at 08:52:45PM -0600, Vitaliy Margolen wrote:
Dr J A Gow wrote:
How to capture these 'lost' contributions is a difficult issue. Maybe a centralized repository for patches could be maintained separate from the main Wine tree and with a very loose method of acceptance (maybe just ensure that it is clearly indicated what the patch is for and what version it can be applied to). This way it would be very easy for a contributor to place a patch somewhere where it is easily accessed by the community. A developer with more time who is interested in it may pick it up and clean it up for inclusion in the tree, but at least the patch is available for others to use, saving re-invention of the wheel.
Why reinvent the wheel? If such people can spend their time chasing down the problem and developing a fix for it, they sure can open a bug in bugzilla, describe theproblem and attach a patch they made. How more simple can it be?
No patches lost, no extra places to look for. And all the information describing the problem. Everything in one place.
And exactly this information should probably be stated in the wine-patches subscription welcome mail.
"If for some reason the Wine patches you submit fail to get applied, then we'd appreciate you taking the effort of submitting your current patch as a new item at bugzilla to help us track your work properly until it's fully applied."
Or, for improved visibility, even state this in the footer of every wine-patches mail sent (probably bad idea, though).
Oh, and a DNS alias (or preferrably forwarder) bugzilla.winehq.org might be useful (after all it's quite common to have that site name, see e.g. bugzilla.kernel.org or bugzilla.mozilla.org etc.).
Andreas
Andreas Mohr wrote:
And exactly this information should probably be stated in the wine-patches subscription welcome mail.
"If for some reason the Wine patches you submit fail to get applied, then we'd appreciate you taking the effort of submitting your current patch as a new item at bugzilla to help us track your work properly until it's fully applied."
Or, for improved visibility, even state this in the footer of every wine-patches mail sent (probably bad idea, though).
Oh, and a DNS alias (or preferrably forwarder) bugzilla.winehq.org might be useful (after all it's quite common to have that site name, see e.g. bugzilla.kernel.org or bugzilla.mozilla.org etc.).
This would be an excellent idea - it would simply highlight the fact that there is an alternative route to providing visibility for patches that are not accepted. I must admit I had always thought of bugzilla as a bug-reporting mechanism and I hadn't thought of using it in this manner: to open a bug specifically in order to present your own fix!
John.
Andreas Mohr wrote:
Why reinvent the wheel? If such people can spend their time chasing down the problem and developing a fix for it, they sure can open a bug in bugzilla, describe theproblem and attach a patch they made. How more simple can it be?
No patches lost, no extra places to look for. And all the information describing the problem. Everything in one place.
And exactly this information should probably be stated in the wine-patches subscription welcome mail.
"If for some reason the Wine patches you submit fail to get applied, then we'd appreciate you taking the effort of submitting your current patch as a new item at bugzilla to help us track your work properly until it's fully applied."
The next question is how long does someone wait till resorting to Bugzilla. Depending on the criteria it could generate a fair bit of noise in the database with a lot of patches that would normally be accepted after a couple of goes. Who is responsible for clearing the bug report after acceptance? Unless you are actually actively pushing the patch for acceptance, the submitter of a patch to Bugzilla would probably be unaware that it had been accepted.
Jeff Latimer
Jeff Latimer wrote:
And exactly this information should probably be stated in the wine-patches subscription welcome mail.
"If for some reason the Wine patches you submit fail to get applied, then we'd appreciate you taking the effort of submitting your current patch as a new item at bugzilla to help us track your work properly until it's fully applied."
The next question is how long does someone wait till resorting to Bugzilla. Depending on the criteria it could generate a fair bit of
-several days :)
As in if some one wants to fix something, they should either provide a test (best choice) or open bug and describe the problem, and the resolution.
noise in the database with a lot of patches that would normally be
This will not be noise but _correct_ use of bug database. Making good bug report is really helpful and 1/2 of the resolution.
accepted after a couple of goes. Who is responsible for clearing the bug report after acceptance? Unless you are actually actively pushing
Of course ultimately bug submitter would be the right person to test if bug is still present in new version and act upon it.
the patch for acceptance, the submitter of a patch to Bugzilla would probably be unaware that it had been accepted.
They don't have to. All they need is update Wine to new version whenever it's released.
Vitaliy
Vitaliy Margolen wrote:
The next question is how long does someone wait till resorting to Bugzilla. Depending on the criteria it could generate a fair bit of
-several days :)
As in if some one wants to fix something, they should either provide a test (best choice) or open bug and describe the problem, and the resolution.
It seems a fairly short time, especially if there is no feedback to say that it is rejected. Thre is another aspect to this, what we are saying is that some developers are able to write good code and won't need to resort to Bugzilla and other developers just won't cut it and Bugzilla is the way for them. I think the discussion on mentoring and developing the WineHQ compilant skills of developers is a more positive way forward.
noise in the database with a lot of patches that would normally be
This will not be noise but _correct_ use of bug database. Making good bug report is really helpful and 1/2 of the resolution.
I was thinking here of the 4,000 patches we have had since March this year and how many would be added to Bugzilla. I expect that a fair few hundred or more would be in this category.
accepted after a couple of goes. Who is responsible for clearing the bug report after acceptance? Unless you are actually actively pushing
Of course ultimately bug submitter would be the right person to test if bug is still present in new version and act upon it.
If this process is being directed at hackers who can't get patches accepted, they probably won't be on the list for long enough to test the patch as they probably will leave.
the patch for acceptance, the submitter of a patch to Bugzilla would probably be unaware that it had been accepted.
They don't have to. All they need is update Wine to new version whenever it's released.
You misunderstood me here, but I think the answer is that the person who make the patch to resolve a Bug report will close the Bug.
Vitaliy
Jeff
Andreas Mohr wrote:
Hi,
On Wed, Sep 20, 2006 at 08:52:45PM -0600, Vitaliy Margolen wrote:
Dr J A Gow wrote:
How to capture these 'lost' contributions is a difficult issue. Maybe a centralized repository for patches could be maintained separate from the main Wine tree and with a very loose method of acceptance (maybe just ensure that it is clearly indicated what the patch is for and what version it can be applied to). This way it would be very easy for a contributor to place a patch somewhere where it is easily accessed by the community. A developer with more time who is interested in it may pick it up and clean it up for inclusion in the tree, but at least the patch is available for others to use, saving re-invention of the wheel.
Why reinvent the wheel? If such people can spend their time chasing down the problem and developing a fix for it, they sure can open a bug in bugzilla, describe theproblem and attach a patch they made. How more simple can it be?
No patches lost, no extra places to look for. And all the information describing the problem. Everything in one place.
And exactly this information should probably be stated in the wine-patches subscription welcome mail.
"If for some reason the Wine patches you submit fail to get applied, then we'd appreciate you taking the effort of submitting your current patch as a new item at bugzilla to help us track your work properly until it's fully applied."
As alternative to bugzilla we have this section in the wiki.
http://wiki.winehq.org/InterestingPatches
This has several hac^H^H^Hpatches that I found uesfull and have used over time. I particularly like the "Mouse Hack" patch http://wiki.winehq.org/PatchMouseHack
The thing is that if a patch is useful it will have a life of its own and I am glad that I have an easy way of getting to them when I want to try them.
Or, for improved visibility, even state this in the footer of every wine-patches mail sent (probably bad idea, though).
Oh, and a DNS alias (or preferrably forwarder) bugzilla.winehq.org might be useful (after all it's quite common to have that site name, see e.g. bugzilla.kernel.org or bugzilla.mozilla.org etc.).
Yes please..
--
Tony Lambregts
On Thursday 21 September 2006 07:09, Dr J A Gow wrote:
After having followed this thread for some time, I feel that there is an aspect that is often missed in the debate.
As I see it, it would appear that Wine contributors fall into essentially two camps. There are those who develop Wine for Wine's sake. This category includes the core developers, and others who just feel strongly about a particular aspect in order to improve it and perfect it. These people have time to spend developing and perfecting their code to meet the necessary high standards for acceptance and would not see the current system of governance to be an issue. These are the very people that would attend Wineconf and discuss the issue!
There is another category, however, and I suspect it is the larger of the two. Some people simply need to quickly fix an aspect of Wine in order simply to get an application working. These individuals, a category into which I fall, are driven by a very different motive. To take an example, my (very) small contribution to Wine was driven by the need to get a commercial ECAD application running, so that I could continue to use the application as a production tool on a production system in order to continue to function as an electronics engineer. In my case, I am also a software developer who believes in feeding useful fixes back to the community, so I used up some of my valuable free time and got the patch accepted. It took approximately three times longer to get the patch accepted than it did to fix the problem in the first place!
I persevered, but I wonder how many other individuals who fall into this category would do the same? Another contractor driven purely by commercial pressures may have just got it working and kept the fix in their own tree. Such people do not have the free time or the inclination to go through the numerous iterations to get the patch accepted. Free time is a rare commodity these days, and most software developers will have other projects. These are not the people who would attend Wineconf and whose opinions can only be solicited through other means. How many Wine trees are there out there containing useful small fixes that see the light of day outside of the developers's box, simply because they do not have the time to struggle through the QA system. A number of these patches could be being lost to the community.
How to capture these 'lost' contributions is a difficult issue. Maybe a centralized repository for patches could be maintained separate from the main Wine tree and with a very loose method of acceptance (maybe just ensure that it is clearly indicated what the patch is for and what version it can be applied to). This way it would be very easy for a contributor to place a patch somewhere where it is easily accessed by the community. A developer with more time who is interested in it may pick it up and clean it up for inclusion in the tree, but at least the patch is available for others to use, saving re-invention of the wheel.
The quality of Wine is important, and a workable QA system is very necessary. However there should be a mechanism to enable widespread dissemination of contributions that for various reasons do not merit direct inclusion in the tree at that time and for which the developer has neither the time nor the inclination to do battle with the QA system.
Just my thoughts.
John.
Thank you Dr Gow, very insightful, but I don't think a technical solution can paper over what is actually a structural (and perhaps a behavioural) problem. Some Transparency would certainly help, but I don't think this is the whole answer.
Rather than harping on about the problem, let me make a few concrete suggestions for improvement. These ideas minimally affect Alexandre's status as maintainer, but add some structure to avoid the downside of the current governance model.
1. Publish the patch acceptance policy - Make sure this is the acceptance policy and not the patch acceptance process. The Patch acceptance policy should be developed by community process and be subject to change (and change control). Perhaps a standing wineconf agenda item here.
2. Adapt the patch acceptance process to create a right of appeal where a patch can be proven to be within the Patch Acceptance policy. Appeal should be independent of and binding on Alexandre - this eliminates one-to-one arguments about patch acceptability while still providing good excellent control. It will also have the effect of reducing Alexandres workload.
2. Have a Wine Developers - Bill of rights - particularly preserve the right to dissent and disagree. To develop freely, most importantly It must recognise, as Dr Gow has so eloquently said, that most Wine developers don't have any interest in WIne and must be treated as valuable volunteers. This has to be respected in the Bill of Rights.
3. Have a community process for properly handling process change.
4. Have a similar wine users Bill of rights - The users of wine need a say.
5. Have a community process for handling these requests according to the BOR.
This will do for a start.
Hello Robert,
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.
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.
On 9/22/06, Robert Lunnon bobl@optushome.com.au wrote:
- Publish the patch acceptance policy - Make sure this is the acceptance
policy and not the patch acceptance process. The Patch acceptance policy should be developed by community process and be subject to change (and change control). Perhaps a standing wineconf agenda item here.
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.
- Adapt the patch acceptance process to create a right of appeal where a
patch can be proven to be within the Patch Acceptance policy. Appeal should be independent of and binding on Alexandre - this eliminates one-to-one arguments about patch acceptability while still providing good excellent control. It will also have the effect of reducing Alexandres workload.
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.
2. Have a Wine Developers - Bill of rights - particularly preserve the right
to dissent and disagree. To develop freely, most importantly It must recognise, as Dr Gow has so eloquently said, that most Wine developers don't have any interest in WIne and must be treated as valuable volunteers. This has to be respected in the Bill of Rights.
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.
3. Have a community process for properly handling process change.
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.
4. Have a similar wine users Bill of rights - The users of wine need a say.
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.
5. Have a community process for handling these requests according to the
BOR.
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.
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.
On Saturday 23 September 2006 11:39, Steven Edwards wrote:
As it stands right now the only reason technically good patches have been rejected is due to concerns over reverse engineering in another project.
I don't see the difference between rejection and "I won't put this in yet because I want to wait and see if X happens" where X is something that might take I long time. This has been known to happen. In a couple of cases I (or somebody working for me) have had this response after going through extensive discussion about how a thing should be done and then doing it that way. Essentially, sometimes Alexandre has ideas about how something should be done but is unwilling to commit. Sometimes he will have a suggestion as to how something should be done and then change his mind later (reflecting the reality that nobody is right *all* of the time).
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.
The present system is self-reinforcing since people who run into significant problems will slow down on (or cease) their contributions.
Things would be much better if there were a system in place that ensured every patch that didn't get in resulted in feedback. Right now it seems only a tiny fraction of patches that don't go in result in feedback. Contributors shouldn't feel like they have to go around begging for feedback every time a patch is not applied. Having a suitable system in place would also prevent the "oops, missed that one, please resubmit" situation.
As things stand it actually involves less effort per patch to maintain a separate branch than to go through the begging-for-feedback process.
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.
Yes, kind of. It would suck to establish a full-scale bureaucracy that might actually slow things down. On the other hand there seems to be a culture here that there is only One True Answer to every problem - in reality two people may disagree about the way a thing should be done and both be equally right.
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.
Bob and I are in somewhat different situations, given that we are developing for customers and both have customers using Winelib apps. I *was* also making some contributions for non work-related stuff but don't do that anymore, in large part because it's such a PITA to do so.
I suspect there is also a significant difference between contributions extending Winelib functionality and contributions on Win32 compatibility. For Winelib functionality there is often a larger design element involved than Win32 were you are just trying to find the best way to implement the same functionality Windows has.
On 9/23/06, Robert Lunnon bobl@optushome.com.au wrote:
- Publish the patch acceptance policy - Make sure this is the acceptance
policy and not the patch acceptance process. The Patch acceptance policy should be developed by community process and be subject to change (and change control). Perhaps a standing wineconf agenda item here.
- Adapt the patch acceptance process to create a right of appeal where a
patch can be proven to be within the Patch Acceptance policy. Appeal should be independent of and binding on Alexandre - this eliminates one-to-one arguments about patch acceptability while still providing good excellent control. It will also have the effect of reducing Alexandres workload.
- Have a Wine Developers - Bill of rights - particularly preserve the right
to dissent and disagree. To develop freely, most importantly It must recognise, as Dr Gow has so eloquently said, that most Wine developers don't have any interest in WIne and must be treated as valuable volunteers. This has to be respected in the Bill of Rights.
Have a community process for properly handling process change.
Have a similar wine users Bill of rights - The users of wine need a say.
Have a community process for handling these requests according to the BOR.
Having a bureaucratic process like that would slow down the wine project more than a handful of rejected patches ever could. There may be structural problems, but bureaucracy is not the solution.
As others have proposed, I think it would be good to implement a system so that rejected patches don't just get forgotten. I don't personally think that bugzilla is a good solution to the problem though -- it's very difficult to use efficiently and the interface is terrible.
A good patch handling system might: - Watch the wine-patches list, automatically adding patches and comments (replies) - Provide a way to categorise/tag patches - Have a way of creating patch sets, which can be downloaded as a single diff (eg, WoW patch set) - Show which patches still apply cleanly - Collect statistics, and be able to show which patches or patch sets are the most downloaded - Allow logged-in users with confirmed email addresses to send comments (replies) and new patches to the wine-patches list through the website - Watch wine-cvs for corresponding accepted patches, and mark the patches that have been accepted
If anyone is interested, I'd be happy to write a little mockup in php or something.
n0dalus.
On Sat, 2006-09-23 at 15:26 +0930, n0dalus wrote:
A good patch handling system might:
- Watch the wine-patches list, automatically adding patches and
comments (replies)
- Provide a way to categorise/tag patches
- Have a way of creating patch sets, which can be downloaded as a
single diff (eg, WoW patch set)
- Show which patches still apply cleanly
- Collect statistics, and be able to show which patches or patch sets
are the most downloaded
- Allow logged-in users with confirmed email addresses to send
comments (replies) and new patches to the wine-patches list through the website
- Watch wine-cvs for corresponding accepted patches, and mark the
patches that have been accepted
Frankly, all we really need is for Alexandre to write a 10-second reply to wine-devel for each patch he rejects.
Thanks, Scott Ritchie
On Saturday 23 September 2006 10:32, Scott Ritchie wrote:
Frankly, all we really need is for Alexandre to write a 10-second reply to wine-devel for each patch he rejects.
On WineConf, we decided against this. That would still slow down the overall patch submission speed. Consider you have a patch that's just fine, but before you sent that, I sent in ten patches with C++ style comments. Alexandre would now have to reply to ten patches with "No C++ style comments" before processing your patch. Everybody reading wine-patches could point out what was wrong with my patches.
Now, we agreed to try something different, two things actually. The first thing is the "ambassador" thing Steve and a couple of other people mentioned before. New contributors would be contacted by someone who would explain the way wine works to them. Secondly, we wanted to make a standard practice of what Mike's been doing for MSI patches. A developer proficient in a certain area of wine will reply to all the patches for his area, do a review and also makes sure they don't disappear into the void.
This should solve most of the problems people (including myself) were having when getting started with wine development.
Cheers, Kai
On Sat, 2006-09-23 at 11:24 +0200, Kai Blin wrote:
On Saturday 23 September 2006 10:32, Scott Ritchie wrote:
Frankly, all we really need is for Alexandre to write a 10-second reply to wine-devel for each patch he rejects.
On WineConf, we decided against this. That would still slow down the overall patch submission speed. Consider you have a patch that's just fine, but before you sent that, I sent in ten patches with C++ style comments. Alexandre would now have to reply to ten patches with "No C++ style comments" before processing your patch. Everybody reading wine-patches could point out what was wrong with my patches.
Now, we agreed to try something different, two things actually. The first thing is the "ambassador" thing Steve and a couple of other people mentioned before. New contributors would be contacted by someone who would explain the way wine works to them. Secondly, we wanted to make a standard practice of what Mike's been doing for MSI patches. A developer proficient in a certain area of wine will reply to all the patches for his area, do a review and also makes sure they don't disappear into the void.
Well, as long as SOMEONE writes the 10-second reply, I suppose it doesn't matter. But until we appoint the equivalent of Mike and MSI for every part of Wine, Alexandre ends up being the default person to do it.
Thanks, Scott Ritchie
Scott Ritchie wrote:
On Sat, 2006-09-23 at 11:24 +0200, Kai Blin wrote:
On Saturday 23 September 2006 10:32, Scott Ritchie wrote:
Frankly, all we really need is for Alexandre to write a 10-second reply to wine-devel for each patch he rejects.
On WineConf, we decided against this. That would still slow down the overall patch submission speed. Consider you have a patch that's just fine, but before you sent that, I sent in ten patches with C++ style comments. Alexandre would now have to reply to ten patches with "No C++ style comments" before processing your patch. Everybody reading wine-patches could point out what was wrong with my patches.
Now, we agreed to try something different, two things actually. The first thing is the "ambassador" thing Steve and a couple of other people mentioned before. New contributors would be contacted by someone who would explain the way wine works to them. Secondly, we wanted to make a standard practice of what Mike's been doing for MSI patches. A developer proficient in a certain area of wine will reply to all the patches for his area, do a review and also makes sure they don't disappear into the void.
Well, as long as SOMEONE writes the 10-second reply, I suppose it doesn't matter. But until we appoint the equivalent of Mike and MSI for every part of Wine, Alexandre ends up being the default person to do it.
Thanks, Scott Ritchie
Well, the way it works at present, nobody is obliged to write a 10 second reply and often don't. There has to be feedback to keep the process moving. I don't receive it and patches languish unapplied, delaying me considerably on tackling new work as I wait for acceptance before proceeding.
Jeff Latimer
On Saturday 23 September 2006 19:24, Kai Blin wrote:
On WineConf, we decided against this. That would still slow down the overall patch submission speed. Consider you have a patch that's just fine, but before you sent that, I sent in ten patches with C++ style comments. Alexandre would now have to reply to ten patches with "No C++ style comments" before processing your patch. Everybody reading wine-patches could point out what was wrong with my patches.
All this points to is a need to automate - sending this reply should be a one-click action. In fact this particular one (and no doubt many others) could be done by a reply-bot.
Other things that could be done by a reply-bot:
unacceptable patch format no patch found in message missing ChangeLog
Perhaps a reply-bot should send out a copy of the guidelines the first time a new contributor submits something to wine-patches (or even to existing contributors when there have been changes to the guidelines).
Robert Lunnon wrote:
- Adapt the patch acceptance process to create a right of appeal where a
patch can be proven to be within the Patch Acceptance policy. Appeal should be independent of and binding on Alexandre - this eliminates one-to-one arguments about patch acceptability while still providing good excellent control. It will also have the effect of reducing Alexandres workload.
I think this process would be completely redundant, so can you give an example of the patches that would meet the "Patch Acceptance policy" but have been rejected by Alexandre?
BTW, you already have a right to appeal - it's a message to wine-devel with a well-reasoned argument.
On Monday 25 September 2006 04:36, Robert Shearman wrote:
Robert Lunnon wrote:
- Adapt the patch acceptance process to create a right of appeal where a
patch can be proven to be within the Patch Acceptance policy. Appeal should be independent of and binding on Alexandre - this eliminates one-to-one arguments about patch acceptability while still providing good excellent control. It will also have the effect of reducing Alexandres workload.
I think this process would be completely redundant, so can you give an example of the patches that would meet the "Patch Acceptance policy" but have been rejected by Alexandre?
I could (If there were a patch acceptance policy) but it'd be pointless at this point.
BTW, you already have a right to appeal - it's a message to wine-devel with a well-reasoned argument.
Ah yes, but is it independent... There is a single acceptance channel, this is poor system design.
Bob
On Thursday 21 September 2006 03:48, Jeremy White wrote:
Wine works fine as-is in my opinion ;)
Which you are entitled to, but my opinion happens to differ. Whether the wine core source has all the patches, (Which it doesn't - many, but not all) isn't relevant, it's the process that they go through that I believe could improve.
For the record, Governance is something we often spend a chunk of time on at each Wine conference.
Brian has written a nice summary of Wineconf on WWN (thanks Brian!), including a reprise of the talk on governance.
Being insufferably long winded, and feeling the need to create a complete record, I would add a few things to what Brian wrote.
First, I think there was clear and essentially unanimous agreement that the current high standards for quality were a Good Thing (TM), including the Holy Order of Writing Conformance Tests.
Second, I think we had fairly clear agreement that so long as he can handle it, it is most efficient to have Alexandre as the sole maintainer. Obviously, the more help he gets from component maintainers (e.g. Mike/MSI, Rob/COM), the better.
Third, I think there was clear agreement that Alexandre is often a Royal Pain In the Ass (RPITA). He ignores patches, responds tersely, and sometimes delivers the occassional kiss of death: "I can't tell you what to change, but your patch is wrong."
However, we, the assembled 30 or so of the most core Wine developers, could not think of a single case where Alexandre had been proven wrong. Nor could we think of a single instance when he had failed to be persuaded by reasonable argument; making a rather compelling case that he is generally right.
We also talk, from time to time, about building some sort of patch tracking system to allow for better management of patches. Something like a 'ticket' system, so people could see the status of their email, whether or not it had been reviewed, etc, etc. I think there is some sense that this might be useful, but it's a sufficiently complex problem, and it has to be written in emacs, that we always defer it for the future.
So I think the strong (if not unamimous) consensus was to continue on as we are, but make an effort to provide an 'ambassador' program of some kind, particularly around folks that are new to Wine.
If you have a specific concrete suggestion for change, this would be a fine time to put it forward.
But if your proposal is largely: "Alexandre should accept more patches", I think you'll find that none of the core Wine developers will support you in that, so it's not worth the effort, at least not in this venue.
Cheers,
Jeremy
I have never said anything of the sort, patches should be accepted according to a policy, and they are, but the policy is largely unstated, and (In my opinion) - wrong. What I have suggested is a changed governance model where Wine development is guided by the collective will toward a community goal and that patch acceptance policy is set by the community - including the user community.
On community, the wine project doesn't represent a community in the sense that Wine has an altruistic purpose to provide value to that community - It doesn't do that because the wine developer base doesn't measure important to Wine users and set policy to provide that value. This means Wine isn't a particularly good Product. Wine is a developers play-thing, Crossover is a Product !
Bob
Robert Lunnon [bobl@optushome.com.au] wrote:
On community, the wine project doesn't represent a community in the sense that Wine has an altruistic purpose to provide value to that community - It doesn't do that because the wine developer base doesn't measure important to Wine users and set policy to provide that value. This means Wine isn't a particularly good Product. Wine is a developers play-thing, Crossover is a Product !
Considering that CrossOver does pay the bill for some part and the major driving force behind Wine is and has been for a long time Codeweavers, no matter if you like it or not, I feel that a Wine with a much more loose acceptance policy but without the Codeweavers support it has now would be not half as far as it is. It would contain all sorts of hacks and workarounds for specific applications but be basically an unmaintainable beast and much further from providing a proper basic infrastructure with COM/DCOM and MSI support (to name some examples) as it should be done rather than as it might just barely work for some popular applications.
A project driven mostly by users most likely is focusing on providing fast fixes that make a specific application work, while Alexandre is specifically trying to make sure that there is a clean (both technically and legally) infrastructure on which one can build for years to come. And which by coincidence will deliver a very good platform to build CrossOver from. It does mean that you can't expect it to immediately deliver support for all the apps you and many others might like but on the other hand it will mean that once new MS technologies get used more widespread it is much easier if not only possible then, to add them and provide faster support for newer apps.
For some part it does boil down to "I want to have fun now" vs "I want to have a technically sound infrastructure that can stand some time". In that sense Wine as is is maybe not a product in the sense of our fast and trigger happy marketing world but it is certainly a product in the sense of engineering and even more so than CrossOver. But then you pay something for CrossOver and not for Wine so maybe that is also why Wine can't and shouldn't really be a product in the sense of marketing.
And as with all OpenSource projects, those that provide the most support in terms of code submissions, testing and documentation get to say the most and I think it has been clear that most of them are quite content if not happy with the modus operandi. Of course Alexandre can be a pain sometimes but he has been always with a reason as far as I can tell.
Rolf Kalbermatter
On Sunday 24 September 2006 00:36, Rolf Kalbermatter wrote:
Robert Lunnon [bobl@optushome.com.au] wrote:
On community, the wine project doesn't represent a community in the sense that Wine has an altruistic purpose to provide value to that community - It doesn't do that because the wine developer base doesn't measure important to Wine users and set policy to provide that value. This means Wine isn't a particularly good Product. Wine is a developers play-thing, Crossover is a Product !
Considering that CrossOver does pay the bill for some part and the major driving force behind Wine is and has been for a long time Codeweavers, no matter if you like it or not, I feel that a Wine with a much more loose acceptance policy but without the Codeweavers support it has now would be not half as far as it is. It would contain all sorts of hacks and workarounds for specific applications but be basically an unmaintainable beast and much further from providing a proper basic infrastructure with COM/DCOM and MSI support (to name some examples) as it should be done rather than as it might just barely work for some popular applications.
A project driven mostly by users most likely is focusing on providing fast fixes that make a specific application work, while Alexandre is specifically trying to make sure that there is a clean (both technically and legally) infrastructure on which one can build for years to come. And which by coincidence will deliver a very good platform to build CrossOver from. It does mean that you can't expect it to immediately deliver support for all the apps you and many others might like but on the other hand it will mean that once new MS technologies get used more widespread it is much easier if not only possible then, to add them and provide faster support for newer apps.
For some part it does boil down to "I want to have fun now" vs "I want to have a technically sound infrastructure that can stand some time". In that sense Wine as is is maybe not a product in the sense of our fast and trigger happy marketing world but it is certainly a product in the sense of engineering and even more so than CrossOver. But then you pay something for CrossOver and not for Wine so maybe that is also why Wine can't and shouldn't really be a product in the sense of marketing.
And as with all OpenSource projects, those that provide the most support in terms of code submissions, testing and documentation get to say the most and I think it has been clear that most of them are quite content if not happy with the modus operandi. Of course Alexandre can be a pain sometimes but he has been always with a reason as far as I can tell.
Rolf Kalbermatter
You make the implicit assumption that you can't have both functionality and technical soundness. I did not suggest a free-for-all, I suggested that a managed objective be established and that "Hacks" that are necessary for functionality and are sufficiently limited in scope can be acceptable if they meet a need of the community.
Secondly, I am starting to get rather annoyed that I am being portrayed as anti Alexandre. This is not the case, Alexandre does a pretty good job given the governance model, but the model itself has severe deficiencies and is not community focused.
Bob
Robert Lunnon wrote:
Which you are entitled to, but my opinion happens to differ. Whether the wine core source has all the patches, (Which it doesn't - many, but not all) isn't relevant, it's the process that they go through that I believe could improve.
The way to get your changes in is not to keep questioning the current process, but to adapt to it. Try fixing your patches. Try asking for guidance. Try testing them on some other platforms.
Getting feedback isn't always easy, so listen when you get it.
If you don't want to go to the effort required to get your patches into Alexandre's tree, they're not going to get in themselves.
Mike
On Thursday 21 September 2006 04:25, Mike McCormack wrote:
Robert Lunnon wrote:
Which you are entitled to, but my opinion happens to differ. Whether the wine core source has all the patches, (Which it doesn't - many, but not all) isn't relevant, it's the process that they go through that I believe could improve.
The way to get your changes in is not to keep questioning the current process, but to adapt to it. Try fixing your patches. Try asking for guidance. Try testing them on some other platforms.
Getting feedback isn't always easy, so listen when you get it.
If you don't want to go to the effort required to get your patches into Alexandre's tree, they're not going to get in themselves.
Mike
Rubbish, The current process is crippling this project, limiting the developer base and reducing community value. Without some healthy dissent it will never change and get better. I am a friend of change, a true believer in the process of continuous improvement. I believe one day, the WIne project will value my contribution - even in dissent.
Bob
Robert Lunnon wrote:
Getting feedback isn't always easy, so listen when you get it.
If you don't want to go to the effort required to get your patches into Alexandre's tree, they're not going to get in themselves.
Mike
Rubbish, The current process is crippling this project, limiting the developer base and reducing community value. Without some healthy dissent it will never
Your "efforts" don't add value to it either. All you trying to do, is create another poor quality software that whole world just can't get rid of.
If you so much like to have bad quality patches, why don't you start your own repository, and grant "patch acceptance prise" to any developer that sends you one.
Then look back (after even few weeks) and see where you are comparing to where Wine is. Then we can continue the conversation.
Until then this is whole bunch of trolling and you should restrain from making remarks about something that you are not a participant of. This is open source project and _everyone_ is free to do _anything_ they'd want to do with their free time.
If you don't like policies of this project, you are welcome to ... leave.
Vitaliy Margolen
Vitaliy Margolen wrote:
Robert Lunnon wrote:
Getting feedback isn't always easy, so listen when you get it.
If you don't want to go to the effort required to get your patches into Alexandre's tree, they're not going to get in themselves.
Mike
Rubbish, The current process is crippling this project, limiting the developer base and reducing community value. Without some healthy dissent it will never
Your "efforts" don't add value to it either. All you trying to do, is create another poor quality software that whole world just can't get rid of.
If you so much like to have bad quality patches, why don't you start your own repository, and grant "patch acceptance prise" to any developer that sends you one.
Then look back (after even few weeks) and see where you are comparing to where Wine is. Then we can continue the conversation.
That's called a straw man argument. He didn't say accept patches willy-nilly.
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.
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.
Until then this is whole bunch of trolling and you should restrain from making remarks about something that you are not a participant of. This is open source project and _everyone_ is free to do _anything_ they'd want to do with their free time.
It's an open forum. And in not way is he not participating. And the _everyone_ and _anything_ don't include Robert posting about his issues with WineHQ's patch process?
And it isn't trolling. It is symptomatic of the fact that Wine is going to yield yet another fork once enough folks get motivated enough to make it happen. Wine hasn't been complete enough for that to be worthwhile, but now that it is approaching 1.0, it no doubt won't be long.
But that doesn't mean WineHQ needs to do anything different, now is there any sign that it is capable of doing anything differently. I'm looking forward to innovation in collaboration and SCM tools that can make this problem manageable (and even though it has great utility, I'm certain Emacs will not be required for using them).
If you don't like policies of this project, you are welcome to ... leave.
Many more leave than stay. And your rudeness just helps that to happen. In case you didn't notice, your entire post was signal free. If Mike is trolling, you've been hooked.
Jim White http://darwine.sf.net/
Hi Jim,
On 9/22/06, Jim White jim@pagesmiths.com wrote:
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.
If you want to add a compatibility hack that works for some apps and breaks others then yes its a straw man argument. If you want to have an api implemented properly without anymore compatibility hacks than what Windows itself implements then the current method is the correct one. We've put a lot of effort in to making the Wine user-focus less of a pain. Winecfg has been developed by many developers who are active contributors. Brian Vincent has written 250+ pages of a book on using Wine and the results of his writting have added other developers in areas in finding where we need to make configuration less of a pain. Supporting aesthetic considerations is one thing to say if your talking about a aesthetic consistent platform like Mac OS X. Dealing with Linux with virtually unlimited window managers, styles, themes, etc..ad nauseam...its is a whole different matter.
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.
Correct. But while CrossOver Office does contain some hacks in the interest of getting a shipping product out the door with a finite amount of developer time, others use stock Wine with very little tweaking already. Case in point CodeWeavers and Google. As far as I remember there are no hacks that Picasa uses that are not in stock Wine. We have a custom installer and a custom package for running that one application really well but make no mistake about it, picasa should always work on stock Winehq as far as I know. I did not work on that project but I seem to recall all of that. Wine is never going to be able to run EVERYTHING out of the box. If you want that then you need VMware or something. CrossOver adds some spit and polish for a few apps but make no mistake about it. At Wineconf I overheard Jeremy White say at least three times he wished we just did a package of Wine with even less of our value add.
What you and others are asking for is the right to add broken hacks for the sake of user experience. We tried that before with the richedit control which was just a dummy wrapper around the edit control. What happened? No one worked on it for like three years until one of CodeWeavers employees got fed up and in his spare time wrote tests, recruited others and did a lot of the grunt work himself to get work on a proper richedit started. Should we sacrifice more infrastructure for the sake of a few quick hacks for a few applications?
Steven Edwards wrote:
What you and others are asking for is the right to add broken hacks for the sake of user experience. ...
I didn't ask for anything and I said I don't think WineHQ is even able to change this process.
Misconstruing the words, intent, and plain meaning expressed by people who offer constructive criticism of WineHQ is a consistent pattern of those defending the status quo (as is a ton of ad hominem noise).
I commented on Vitaly's comments as they we're wildly hypocritical. And I offered perspective on the roots of the issue that Robert raised. Which reminds me that I should also have pointed out to Vitaly that if he thinks this issue is such a trolling non-issue then why did it rank a session @ Wineconf, taking up the valuable face-to-face time of the hardest core of the hard core Wine developers.
I also offered my expectation, optimistic as ever, that OSS will lead to innovation that fills unmet needs.
Jim
"Jim White" jim@pagesmiths.com wrote:
Your "efforts" don't add value to it either. All you trying to do, is create another poor quality software that whole world just can't get rid of.
If you so much like to have bad quality patches, why don't you start your own repository, and grant "patch acceptance prise" to any developer that sends you one.
Then look back (after even few weeks) and see where you are comparing to where Wine is. Then we can continue the conversation.
That's called a straw man argument. He didn't say accept patches willy-nilly.
We must be reading/understanding that differently. Please reread Mike's answer to Robert's e-mail.
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.
And what's the problem with xrender.c in your opinion? Where are your patches for that problems if any?
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.
No, that's clearly a technical matter, and has nothing to do with user's expectations. There is no such a thing as a "wine user-focused developer", but there is such a thing as commercial software development. Feel the difference.
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 just curious, did you send a single patch to wine-patches, or all this word-playing has nothing to do with technical side of the process?
On Saturday 23 September 2006 16:36, Dmitry Timoshkov wrote:
"Jim White" jim@pagesmiths.com wrote:
<snip>
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.
No, that's clearly a technical matter, and has nothing to do with user's expectations. There is no such a thing as a "wine user-focused developer", but there is such a thing as commercial software development. Feel the difference.
Let me answer this, as a User-Focused non-commercial developer I feel the difference every time I apply my custom patch tree to WineHQ wine to produce a solaris binary, thus the argument you give is non sequitur due to the fact that self evidently I fit the exact characterisation you assert does not exist.
Bob
Jim White wrote:
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.
And that is wrong? Wine being Open Source that everybody can download I'm not sure how you would get many people to pay for it. Packaging alone won't be a good business model because there are many Linux distributors who will and do that too for no additional cost.
Many more leave than stay. And your rudeness just helps that to happen. In case you didn't notice, your entire post was signal free. If Mike is trolling, you've been hooked.
I agree with you that Vitaly's post wat unnecessarily rude and harsh, especially considering that Bob did submit a bunch of patches no matter if they were accepted into Wine or not.
Rolf Kalbermatter
On Sunday 24 September 2006 01:06, Rolf Kalbermatter wrote:
Jim White wrote:
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.
And that is wrong? Wine being Open Source that everybody can download I'm not sure how you would get many people to pay for it. Packaging alone won't be a good business model because there are many Linux distributors who will and do that too for no additional cost.
Many more leave than stay. And your rudeness just helps that to happen. In case you didn't notice, your entire post was signal free. If Mike is trolling, you've been hooked.
I agree with you that Vitaly's post wat unnecessarily rude and harsh, especially considering that Bob did submit a bunch of patches no matter if they were accepted into Wine or not.
Rolf Kalbermatter
Actually, most patches *are* accepted - but I keep labouring, this isn't the point, I am promoting the concept that Wine should be for the users and that the patch acceptance policy and behaviour management should support a user (Customer) focus and need to be transparent.
Bob
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.
The current process is crippling this project, limiting the developer base and reducing community value. Without some healthy dissent it will never change and get better. I am a friend of change, a true believer in the process of continuous improvement. I believe one day, the WIne project will value my contribution - even in dissent.
We value your contribution, however it's even more valuable to have developers that listen to feedback and fix their broken patches rather than just complaining loudly.
Since you know better, how about maintaining your own Wine tree and showing us how it's done?
Mike
----- Original Message ---- From: Mike McCormack mike@codeweavers.com To: bobl@optushome.com.au Cc: wine-devel@winehq.org; Marcus Meissner marcus@jet.franken.de Sent: Friday, September 22, 2006 11:42:36 PM Subject: Re: Governance revisited
The current process is crippling this project, limiting the developer baseand reducing community value. Without some healthy dissent it will never change and get better. I am a friend of change, a true believer in the process of continuous improvement. I believe one day, the WIne project will value my contribution - even in dissent.
We value your contribution, however it's even more valuable to have developers that listen to feedback and fix their broken patches rather than just complaining loudly.
Since you know better, how about maintaining your own Wine tree and showing us how it's done?
Mike
-----------------------------
I think Bob, Jim and co. were very diplomatic in their recommendations, and I firmly believe that they symbolize the opinions of a much larger group of people. I don't think they've overstepped their boundaries at all, have "complained" or rushed-in to proclaim that they are "know-it-alls". What they do realize is that the process can be improved and have tried to provide recommendations. I'm also very suprised that they have been accused of "trolling" when I didn't see it that way at all - I think someone who was "complaining" or "trolling" because their patches never/ rarely make it in would be MUCH less constructive. You guys, you don't have to be on the "defensive" because Bob, Jim, and co. are "attacking" you.
Watching and being on this list for a few years now, it's no secret that this topic has come up over and over again - clearly, they aren't the only ones feeling this way and the "problem" persists. We've seen MANY discouraged developers leave because of situations like this, and I believe this hurts the project. Yeah, the team can say "hey, we have no problem with it", but I think that's only because those who disagree have been "scared away". As far as the recommendation to fork the tree, I wouldn't be suprised if that happens because it's already happened once before - of course, relations between this team and with Transgaming aren't all that great; so, I doubt they would want to share their development process.
I think this team has done an incredible job with Wine - heck I've made it a point to stop by the CodeWeavers booth the last two year at LinuxWorld to say how much I love the work you guys do (sometimes, I'm the only one there). However, I can't help but believe that this project can evolve MUCH faster and better to gain the respect that it deserves.
I've been using Wine for a little over 2 years now (it's the first app I've ever installed on Linux, and its what kept me on Linux), but from a user's perspective, I have seen very little progress (and in some cases, steps backwards.) And frankly said, it really sucks to hear that the developers here don't place user needs/ value higher on their priority list. Granted, Wine is free software, and I could off and do my own thing, but speaking merely from a personal satisfaction perspective, when I develop something, what really makes me happy is knowing that the person using my app REALLY enjoys and makes use of it. That's why it's always high on my priority list. If I don't have that going for me, I have no reason to develop the app.
I just want to close with this: I'm not trolling (the team should know this because I've been on the list for awhile) and I certainly don't think that anyone else here has trolled around this thread.
A Wine Fan, Hiji
"Hiji" hijinio@yahoo.com wrote:
----- Original Message ---- From: Mike McCormack mike@codeweavers.com To: bobl@optushome.com.au Cc: wine-devel@winehq.org; Marcus Meissner marcus@jet.franken.de Sent: Friday, September 22, 2006 11:42:36 PM Subject: Re: Governance revisited
The current process is crippling this project, limiting the developer baseand reducing community value. Without some healthy dissent it will never change and get better. I am a friend of change, a true believer in the process of continuous improvement. I believe one day, the WIne project will value my contribution - even in dissent.
We value your contribution, however it's even more valuable to have developers that listen to feedback and fix their broken patches rather than just complaining loudly.
Since you know better, how about maintaining your own Wine tree and showing us how it's done?
Mike
I intentionally left Mike's answer and the mail he were answering to. I absolutely don't understand why you addressed your message to him.
[skipped]
I think this team has done an incredible job with Wine - heck I've made it a point to stop by the CodeWeavers booth the last two year at LinuxWorld to say how much I love the work you guys do (sometimes, I'm the only one there). However, I can't help but believe that this project can evolve MUCH faster and better to gain the respect that it deserves.
Everyone who complaints about "problems" with patch acceptance policy seem to claim that, but my impression is that complaints are going from technically incompetent people, who just "feels" that the process can be improved, but can't explain it in developer's language (i.e. in technical words) how.
On Sun, 2006-09-24 at 12:36 +0900, Dmitry Timoshkov wrote:
Everyone who complaints about "problems" with patch acceptance policy seem to claim that, but my impression is that complaints are going from technically incompetent people, who just "feels" that the process can be improved, but can't explain it in developer's language (i.e. in technical words) how.
One thing to be careful about is the ever growing trend of forming a very tightly coupled in-group. It is very easy to happen: most top developers work for the same company, they are extremely competent, and have the technical argument on their side. It is way too easy to feel righteous.
This is a big problem, as it elevates the (already high) barrier to entry to a dangerous altitude. And the feedback is positive, as people are being put off, the in-group grows tighter, etc.
The net is littered with amazingly smart and competent teams that killed projects via this process: *BSD, XFree86, etc. The human aspect of engineering a lively community is still a black art, so we have to tread carefully.
Now, for the problem at hand: I think people's intuition that something is off has a seed of truth. And I find it difficult to say that because I think Alexandre does an amazing job. He is probably by far the person that had the largest (positive) influence on me from a professional perspective.
To my mind, Alexandre is the Roger Federer and Michael Schumacher of software development. He is never wrong.
And paradoxically, I think this is part of the problem. He is just too good for mere mortals. And I think a lot of folks get discouraged because it is just too much work to reach Alexandre's standards. This is even more difficult when you have to guess Alexandre's ideas about how you should properly solve the problem :)
IOW, I think we're missing on an important human aspect of development: the need to compete, and show that you can do it better than the other guy. I always found it interesting on LKML, how Linus lets in sometimes dubious code, and that results in an effervescence of work!
It's like bad stuff motivates people to show that things can be done better. I think Tom Tromey is onto something: http://tromey.com/blog/?p=252
So, what is the solution? Let in crappy code? Certainly not. And in all honesty, how can we ask Alexandre to let in stuff that he know sucks? I can appreciate how silly and difficult that would be.
Bottom line, I don't know. At most I can say that sometimes I wish Alexandre would be a bit more impulsive, and just let (a selected few) things in that people want. Maybe this way we generate more excitement, and the tiny bit of quality drop we pay with would be worth it.
YMMV :)
On Monday 25 September 2006 13:16, Dimi Paun wrote:
On Sun, 2006-09-24 at 12:36 +0900, Dmitry Timoshkov wrote:
Everyone who complaints about "problems" with patch acceptance policy seem to claim that, but my impression is that complaints are going from technically incompetent people, who just "feels" that the process can be improved, but can't explain it in developer's language (i.e. in technical words) how.
One thing to be careful about is the ever growing trend of forming a very tightly coupled in-group. It is very easy to happen: most top developers work for the same company, they are extremely competent, and have the technical argument on their side.
Is it, or is it that the culture attracts "yes" men? Considering the text you quoted, who would want to work for CodeWeavers if they do differ in opinion (or, quite frankly, even if they don't)? People are more likely to go where they will be appreciated.
"We know we're right, because we're all very clever and we all agree".
It is way too easy to feel righteous.
The text you quoted exhibits far more serious problems than that.
This is a big problem, as it elevates the (already high) barrier to entry to a dangerous altitude. And the feedback is positive, as people are being put off, the in-group grows tighter, etc.
Indeed. Consider again the paragraph you quoted. Not only is it ad-hominem, it is a classic example of forestalling disagreement. Don't speak up to disagree or you'll be labelled incompetent. The accusation is far more likely to be more an indication of the maturity of its maker rather than a reflection of truth.
If I say I've been coding since I was 14 (in those days home computers had less than 1% penetration in Australia), in assembly language since shortly after that and raw machine code not long after, having memorised the instruction set, then was widely recognised as the most capable Comp Sci student at the top university for Computer Science in the state, and that I only employ people who are proven geniuses, would it make a difference? While true, it's all irrelevant to the argument at hand. The accusation made above is also irrelevant.
There is a valid point being made here - the black hole of patch submission *is* turning away developers. As one anecdote, one person currently on my staff - and note above - tried submitting patches to Wine in a personal capacity and would most likely still be submitting patches, but found the problems being discussed rendered it not worth his effort. I don't have to walk very far to find somebody else with the same opinion of Wine.
The present system turns people off even before you've had time to learn whether they are capable or not.
To my mind, Alexandre is the Roger Federer and Michael Schumacher of software development. He is never wrong.
Everybody is wrong sometimes, although I have noticed that when somebody gets a sufficiently high reputation people stop noticing when they do get things wrong. I say this from the perspective of somebody who is sometimes in the situation of being the person with that reputation. As an example I have had people say to me "it's easy to speak up when you get everything right", to which I have responded that "I do get things wrong, you just don't notice when I do."
Actually, some people arguing in support of the status quo have pointed out that Alexandre sometimes accepts things he previously rejected after an argument being made successfully in favour of a change - in such a case if we are calling things black-and-white wrong or right, then either the first decision or the revised one must be wrong. A rejection cannot be an incontrovertible sign of the wrongness of the contribution.
Of course making an argument in favour of a particular contribution is somewhat challenging, if not impossible, when you're not being told why Alexandre perceives his solution to be better, which seems to be most of the time. Often the difference may be a mere matter of style - Alexandre seems to be more comfortable with copy-and-paste coding than I am, for example - but if it's more than a matter of style the rejection of the patch should give the reason. It saves no time to require people to chase up Alexandre for reasons unless by "saving time" you mean the person doesn't bother and so the change never gets in.
This is even more difficult when you have to guess Alexandre's ideas about how you should properly solve the problem :)
Actually, this is probably 90%+ of the problem. If patch submission weren't a black hole in which it either gets through or you have to go begging for feedback like an errant schoolboy, you wouldn't see nearly the volume of complaints you do.
Worse are the times when you spend considerable time reworking a patch to his specifications and he still won't let it in. One of my staff had this problem, and the answer from Alexandre was that he wasn't going to let *anything* in covering that area no matter how it was implemented until it had been proven in the field (effectively forcing a branch). That's pretty soul-destroying stuff. That staff member resigned a short time later, and while he gave other reasons his frustration with dealing with Alexandre had been showing, and his whole job revolved around improving Wine.
IOW, I think we're missing on an important human aspect of development: the need to compete, and show that you can do it better than the other guy.
This is something that abates with maturity... at least for people who don't get stuck in a One True View Of The World mind-set.
Bottom line, I don't know. At most I can say that sometimes I wish Alexandre would be a bit more impulsive, and just let (a selected few) things in that people want.
I don't think this is necessary, at least
"Troy Rollo" wine@troy.rollo.name wrote:
If I say I've been coding since I was 14 (in those days home computers had less than 1% penetration in Australia), in assembly language since shortly after that and raw machine code not long after, having memorised the instruction set, then was widely recognised as the most capable Comp Sci student at the top university for Computer Science in the state, and that I only employ people who are proven geniuses, would it make a difference?
Very nice picture of a man with overestimated personal evaluation.
[skipped]
This is even more difficult when you have to guess Alexandre's ideas about how you should properly solve the problem :)
Actually, this is probably 90%+ of the problem. If patch submission weren't a black hole in which it either gets through or you have to go begging for feedback like an errant schoolboy, you wouldn't see nearly the volume of complaints you do.
Worse are the times when you spend considerable time reworking a patch to his specifications and he still won't let it in. One of my staff had this problem, and the answer from Alexandre was that he wasn't going to let *anything* in covering that area no matter how it was implemented until it had been proven in the field (effectively forcing a branch). That's pretty soul-destroying stuff. That staff member resigned a short time later, and while he gave other reasons his frustration with dealing with Alexandre had been showing, and his whole job revolved around improving Wine.
How many projects have you ever participated in? Every developers' mailing list of an open source I personally participated in *doesn't guarantee* not only patch acceptance, but even a reply with explanations why the patch has been silently dropped, and it doesn't matter how many maintainers a project has. Why do you request that from Wine, and particularly from Alexandre?
Alexandre is not a robot, he is a human. Please take that into account.
It's a metter of the fact, that if you can't cope with other people's requirements, you can't work in a team.
"Dimi Paun" dimi@lattica.com wrote:
Bottom line, I don't know. At most I can say that sometimes I wish Alexandre would be a bit more impulsive, and just let (a selected few) things in that people want. Maybe this way we generate more excitement, and the tiny bit of quality drop we pay with would be worth it.
Dimi, I thought you were aware of it, and Alexandre at least at previous WineConf stated that he accepts dubious code in cases, when he sees that nobody works on some component: that components were OLE/COM, DDraw/D3D, BiDi at some point.
On Mon, 2006-09-25 at 19:47 +0900, Dmitry Timoshkov wrote:
Dimi, I thought you were aware of it, and Alexandre at least at previous WineConf stated that he accepts dubious code in cases, when he sees that nobody works on some component: that components were OLE/COM, DDraw/D3D, BiDi at some point.
Yes, you are correct. I was trying to make a point, and I couldn't let reality mess with that :)
In fact, I must say that the most fun I had with Wine was when Alexandre let me run with listview a few year back. He clearly committed patches that weren't perfect, but I appreciated that because that's how I work: I like to do several iterations, maybe redo the code several times, but commit the intermediate steps.
If I would have had to refine each patch more, I would have given up working on it, since it wouldn't have been nearly as fun for me.
Truth of the matter is that in the meantime listview broke, and there was a dip in quality. However, by the time I was done, I think Wine was in better shape than when I started. For me, that worked.
Unfortunately, that doesn't say much. Whom, when, and where you let people play is a black art, and there can not be clear policy about it. In fact, clear policy in these matters would defeat the purpose, as it would take that 'play' aspect out of it.
"Dimi Paun" dimi@lattica.com wrote:
In fact, I must say that the most fun I had with Wine was when Alexandre let me run with listview a few year back. He clearly committed patches that weren't perfect, but I appreciated that because that's how I work: I like to do several iterations, maybe redo the code several times, but commit the intermediate steps.
And Alexandre explained that as well :-) If he sees that a person really grasps and understands the code, he reviews his patches much more freely, and allows some sloppiness in his code, hoping that it improves with time.
On Saturday 23 September 2006 18:10, Hiji wrote:
I think Bob, Jim and co. were very diplomatic in their recommendations, and I firmly believe that they symbolize the opinions of a much larger group of people. I don't think they've overstepped their boundaries at all, have "complained" or rushed-in to proclaim that they are "know-it-alls". What they do realize is that the process can be improved and have tried to provide recommendations. I'm also very suprised that they have been accused of "trolling" when I didn't see it that way at all - I think someone who was "complaining" or "trolling" because their patches never/ rarely make it in would be MUCH less constructive. You guys, you don't have to be on the "defensive" because Bob, Jim, and co. are "attacking" you.
Well, I just fail to see some of the points. Robert Lunnon complains there is no appeal process about Wine patches. This is true. But most other successful OSS projects out there do the same. I've never seen this sort of stuff come up on samba-technical. Why is it a problem in Wine? "My way or the highway" is an accepted gouvernance model in OSS. Besides, at WineConf we had a consent to keep it that way.
To be frank, I didn't understand what Jim White's point was.
Watching and being on this list for a few years now, it's no secret that this topic has come up over and over again - clearly, they aren't the only ones feeling this way and the "problem" persists. We've seen MANY discouraged developers leave because of situations like this, and I believe this hurts the project.
Can you point out a couple of those? People who send some good patches that didn't make it in and who left again?
Yeah, the team can say "hey, we have no problem with it", but I think that's only because those who disagree have been "scared away". As far as the recommendation to fork the tree, I wouldn't be suprised if that happens because it's already happened once before - of course, relations between this team and with Transgaming aren't all that great; so, I doubt they would want to share their development process.
That fork was on a licensing issue. If you have a couple of hours to waste, it's a fun read. It had nothing to do with policy though. We're comparing apples and oranges here.
I think this team has done an incredible job with Wine - heck I've made it a point to stop by the CodeWeavers booth the last two year at LinuxWorld to say how much I love the work you guys do (sometimes, I'm the only one there). However, I can't help but believe that this project can evolve MUCH faster and better to gain the respect that it deserves.
I think the bigger issue that keeps developers away is: It's damn hard, and the Win32 API sucks. :) But that might be my personal opinion.
I've been using Wine for a little over 2 years now (it's the first app I've ever installed on Linux, and its what kept me on Linux), but from a user's perspective, I have seen very little progress (and in some cases, steps backwards.)
Now that really can't be. I couldn't play most of my games in Wine two years ago, and now I can play most of them. If you don't call that progress, what else do you want?
And frankly said, it really sucks to hear that the developers here don't place user needs/ value higher on their priority list. Granted, Wine is free software, and I could off and do my own thing, but speaking merely from a personal satisfaction perspective, when I develop something, what really makes me happy is knowing that the person using my app REALLY enjoys and makes use of it. That's why it's always high on my priority list. If I don't have that going for me, I have no reason to develop the app.
Let me answer this from my own perspective. As you can see in my signature, wine isn't the only FOSS project I'm working on. In fact, I only got started with Wine development because I was accepted into the Google Summer of Code 2005, so I was paid to work on Wine. I worked on an obscure area of Wine, and I so far heard from one user who seems to need this. I sent a fix for his problem, but I didn't hear back from him. So obviously my personal satisfaction comes from getting my personnal test applications to work. (And the times I got paid for this, it was a job.) Now, while I don't think most wine developers have this background, I figure most of them work on a certain area to scratch an itch they're having, I wonder what's wrong about this policy.
I just want to close with this: I'm not trolling (the team should know this because I've been on the list for awhile) and I certainly don't think that anyone else here has trolled around this thread.
You're not trolling, but you are very vague.
Cheers, Kai
On Saturday 23 September 2006 16:42, Mike McCormack wrote:
The current process is crippling this project, limiting the developer base and reducing community value. Without some healthy dissent it will never change and get better. I am a friend of change, a true believer in the process of continuous improvement. I believe one day, the WIne project will value my contribution - even in dissent.
We value your contribution, however it's even more valuable to have developers that listen to feedback and fix their broken patches rather than just complaining loudly.
Thats not helpful, I'm trying to engage in a discussion on governance, I've long since given up on trying to argue with the current system, If a patch is rejected it goes to my local tree.
Since you know better, how about maintaining your own Wine tree and showing us how it's done?
Mike
Self evidently thats what I have to do until some core functionality patches find their way into WineHQ wine. It's not particularly hard, but it is time consuming to manage merge conflicts.
On Monday 25 September 2006 23:05, Robert Lunnon wrote:
On Saturday 23 September 2006 16:42, Mike McCormack wrote:
Since you know better, how about maintaining your own Wine tree and showing us how it's done?
Self evidently thats what I have to do until some core functionality patches find their way into WineHQ wine. It's not particularly hard, but it is time consuming to manage merge conflicts.
Actually, you're not, at least not in the sense that Mike is suggesting. On the other hand Mike's suggestion is a bit of a red herring since the effort involved in maintaining a second tree with multiple contributors *and* keeping that in sync with WineHQ is significant in terms of management of merge conflicts. When the changes on the branch are all your own you will presumably know (or be in a position to easily figure out) the correct resolution to each conflict, but with lots of contributions from lots of people, this job is significantly harder and more time consuming.
If there were such an alternative tree that had better patch management I would switch in a second, but if there were a significant number of contributors it could easily take a full time person to just manage merge conflicts. At this stage I don't know if there's enough commercial interest in such a tree to pay for that (although if there are people who are lurking who would be interested, let me know off-list).
One alternative is a set of cascading trees in which each participant maintains their own tree that is WineHQ plus their own changes, updated to some agreed WineHQ commit at the same time each week, with these trees then merged into a common tree. That might make it merge conflict management easier, but would also result in some lag between updates to Wine and updates to the merged tree.
Since you know better, how about maintaining your own Wine tree and showing us how it's done?
Self evidently thats what I have to do until some core functionality patches find their way into WineHQ wine. It's not particularly hard, but it is time consuming to manage merge conflicts.
It's very easy to say Alexandre should do this or Alexandre shouldn't do that when you haven't put yourself in his shoes, and tried to do what he's doing.
Fact is, it's a difficult and time consuming job. By reviewing your patches, Alexandre is doing you and everybody else in the Wine community a service.
Secondly, patches that get no response are not "rejected". You should consider them as "not obviously correct" rather than incorrect. The problem may be simply that they're too complex to review and reply to in a short amount of time.
I don't think a web based patch tracking system will work for reasons pointed out by Jeremy in another mail, and that it would be very difficult to integrate it with Alexandre's work flow without wasting more of his time.
So I have some possible ways to enhance the current procedures:
1) When somebody has sent a patch to wine-patches that hasn't been applied for a few days, write to wine-devel and request that others review it.
2) Enter into bugzilla the *problem* that your patch addresses (not the patch itself), and attach the patch to the bug.
These may not be to your liking, but if they're not, fork Wine and maintain your own public Wine tree, as Alexandre's tree is maintained using Alexandre's methods.
Mike
On Tuesday 26 September 2006 19:35, Mike McCormack wrote:
Since you know better, how about maintaining your own Wine tree and showing us how it's done?
Self evidently thats what I have to do until some core functionality patches find their way into WineHQ wine. It's not particularly hard, but it is time consuming to manage merge conflicts.
It's very easy to say Alexandre should do this or Alexandre shouldn't do that when you haven't put yourself in his shoes, and tried to do what he's doing.
Fact is, it's a difficult and time consuming job. By reviewing your patches, Alexandre is doing you and everybody else in the Wine community a service.
Secondly, patches that get no response are not "rejected". You should consider them as "not obviously correct" rather than incorrect. The problem may be simply that they're too complex to review and reply to in a short amount of time.
I don't think a web based patch tracking system will work for reasons pointed out by Jeremy in another mail, and that it would be very difficult to integrate it with Alexandre's work flow without wasting more of his time.
So I have some possible ways to enhance the current procedures:
- When somebody has sent a patch to wine-patches that hasn't been
applied for a few days, write to wine-devel and request that others review it.
- Enter into bugzilla the *problem* that your patch addresses (not the
patch itself), and attach the patch to the bug.
These may not be to your liking, but if they're not, fork Wine and maintain your own public Wine tree, as Alexandre's tree is maintained using Alexandre's methods.
Mike
Well thats at least a reasoned response, even if I don't agree with the reasoning. But again you simply miss the point. I don't care that Alexandre doesn't move my patches (because its not true that he doesn't) and since I now have a patch management capability which allows me to manage my local tree and keep in sync with wineHQ. But wine is my/our toy now as well as Alexandre's and I for one want to make it better.
In that Alexandre and I should be in agreement and perhaps he should consider some of the positive measures I have suggested.
Bob
Robert Lunnon bobl@optushome.com.au writes:
Well thats at least a reasoned response, even if I don't agree with the reasoning. But again you simply miss the point. I don't care that Alexandre doesn't move my patches (because its not true that he doesn't) and since I now have a patch management capability which allows me to manage my local tree and keep in sync with wineHQ. But wine is my/our toy now as well as Alexandre's and I for one want to make it better.
In that Alexandre and I should be in agreement and perhaps he should consider some of the positive measures I have suggested.
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.
On Tuesday 26 September 2006 22:09, Alexandre Julliard wrote:
Robert Lunnon bobl@optushome.com.au writes:
Well thats at least a reasoned response, even if I don't agree with the reasoning. But again you simply miss the point. I don't care that Alexandre doesn't move my patches (because its not true that he doesn't) and since I now have a patch management capability which allows me to manage my local tree and keep in sync with wineHQ. But wine is my/our toy now as well as Alexandre's and I for one want to make it better.
In that Alexandre and I should be in agreement and perhaps he should consider some of the positive measures I have suggested.
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.
Pleased to, I'll put my explanations along with suggestions into a material form and present them here in a new thread.
Bob
-
Alexandre Julliard -
Andreas Mohr -
Brian Vincent -
Dimi Paun -
Dmitry Timoshkov -
Dmitry Timoshkov -
Dr J A Gow -
Hiji -
Jeff Latimer -
Jeremy White -
Jim White -
Kai Blin -
Marcus Meissner -
Mike McCormack -
n0dalus -
Robert Lunnon -
Robert Shearman -
Rolf Kalbermatter -
Scott Ritchie -
Steven Edwards -
Tony Lambregts -
Troy Rollo -
Vijay Kiran Kamuju -
Vitaliy Margolen