I can't understand why the members of the Wine project are always complaining about lack of manpower. The lack of manpower is probably due to there being different flavours of Wine developed by different companies. If all the companies worked together on a single WinXP-Pro-emulating flavour of Wine, the manpower problem would be solved. There would be other advantages to this: - a) Windows API functions would be implemented more quickly. b) There would be better support for the latest Windows applications. c) People would no longer have problems running applications that fail to work simply because they need support files from more than one Wine flavour. d) There wouldn't be multiple teams of people pointlessly trying to implement the same Windows API functions as each other for different flavours of Wine, because each team would no longer be going its own way.
___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
Hi Alex,
Firstly, Wine is not an emulator, it it a binary loader and an implementation of the Win32 API.
Alex Tanner wrote:
companies. If all the companies worked together on a single WinXP-Pro-emulating flavour of Wine, the manpower problem would be solved.
Different companies have different goals. For CodeWeavers, the goal is not to full emulate any version of Windows, but to allow more useful applications that were originally written for Windows to work.
IMO, the best way to contribute to Wine is to test applications, and write patches to fix them :)
Mike
Firstly, Wine is not an emulator, it it a binary loader and an implementation of the Win32 API.
Bingo. It irritates me when people call Wine an emulator. ALEX, did you know that Wine stands for "Wine Is Not an Emulator"??
Hiji
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Mon, 05 Sep 2005 11:30:41 -0700, Hiji wrote:
Firstly, Wine is not an emulator, it it a binary loader and an implementation of the Win32 API.
Bingo. It irritates me when people call Wine an emulator. ALEX, did you know that Wine stands for "Wine Is Not an Emulator"??
It's playing with words. I happen to think it is an emulator and I usually call it that ;)
thanks -mike
Mike Hearn wrote:
On Mon, 05 Sep 2005 11:30:41 -0700, Hiji wrote:
Firstly, Wine is not an emulator, it it a binary loader and an implementation of the Win32 API.
Bingo. It irritates me when people call Wine an emulator. ALEX, did you know that Wine stands for "Wine Is Not an Emulator"??
It's playing with words. I happen to think it is an emulator and I usually call it that ;)
thanks -mike
So a Chevy is a Ford emulator, because it can use the same gas, right?
No, of course not. Now, if the gas had to be converted to a completely different substance before it could power the car, then it would probably be an emulator.
WINE doesn't change the gas, it's just an engine add-on that just lets you burn unleaded or diesel.
And so ends "Lousy Analogy Theater". We now return you to your normal program, already in progress.
-J
On Mon, 05 Sep 2005 18:21:18 -0500, Evil wrote:
No, of course not. Now, if the gas had to be converted to a completely different substance before it could power the car, then it would probably be an emulator.
Ah, car analogies, the developers favourite tool :)
From a dictionary:
"em·u·late: Computer Science. To imitate the function of (another system), as by modifications to hardware or software that allow the imitating system to accept the same data, execute the same programs, and achieve the same results as the imitated system."
Seems like a good description of Wine to me. It imitates the Win32 API.
"Mike Hearn" mh@codeweavers.com wrote:
From a dictionary:
"em·u·late: Computer Science. To imitate the function of (another system), as by modifications to hardware or software that allow the imitating system to accept the same data, execute the same programs, and achieve the same results as the imitated system."
You've just called Linux a Unix emulator :-) I'm always tempted to mention DRDOS, x86 processors, PC motherboards, PC BIOS'es around, VGA compatible video cards, Soundblaster compatible sound cards, netword cards of all flavours, language compilers, etc: all of them are the emulators according to the definition above.
The better word is "clone" if you don't like a wordy "independent implementation".
-- Dmitry.
On 9/9/05, Dmitry Timoshkov dmitry@baikal.ru wrote:
The better word is "clone" if you don't like a wordy "independent implementation".
Heh, no that would be ReactOS. I always like the term "compatibility layer" when speaking of Wine.
Thanks Steven
Mike Hearn wrote:
From a dictionary:
"em·u·late: Computer Science. To imitate the function of (another system), as by modifications to hardware or software that allow the imitating system to accept the same data, execute the same programs, and achieve the same results as the imitated system."
Seems like a good description of Wine to me. It imitates the Win32 API.
By this definition:
Windows XP = Windows 9x Emulator Windows 9x = Dos Emulator etc...
In fact, this definition makes a confusing amount of software and hardware an "emulator" solely by virtue of conforming to standards or through backwards compatibility. There's not even an exception that says the "same program" has to be binary code. So, every interpretive programming language, but first implementations, is an "emulator".
I refuse to use such a loose definition, probably written by an English major who didn't fully comprehend what he was writing, simply because he was paid to write it. I don't think any of us should, unless you also agree that purchased software always does things more correctly than free software. :) So we need to make sure the media gets it right:
"em·u·late: Computer Science, Software: Imitation of the function of (another system), by dynamic recompilation or interpretive translation as to allow the imitating system to accept the same data, execute the same binary programs, and achieve the same results as the imitated system."
"em·u·late: Computer Science, Software: Imitation of the function of (another system), by dynamic recompilation or interpretive translation as to allow the imitating system to accept the same data, execute the same binary programs, and achieve the same results as the imitated system."
I like that one. At least it meshes well with what people mean when they use the word.
Cheers, Kuba
On Mon, 5 Sep 2005 06:24, Alex Tanner wrote:
If all the companies worked together on a single WinXP-Pro-emulating flavour of Wine, the manpower problem would be solved.
Not really. Firstly there is not (yet) enough commercial interest in contributing to Wine development to provide the manpower, although that is changing.
Secondly, even if there were sufficient manpower, the way the Wine project is currently structured would prevent the manpower from being used efficiently.
On Mon, 5 Sep 2005, Troy Rollo wrote:
[...]
Secondly, even if there were sufficient manpower, the way the Wine project is currently structured would prevent the manpower from being used efficiently.
What makes you say that? What would need changing to efficiently accomodate more developpers?
I'm asking because I don't see a problem with the current organisation but I may be missing something. If there are issues it's best to get them out in the open so we can work on fixing them.
What makes you say that? What would need changing to efficiently accomodate more developpers?
I'm asking because I don't see a problem with the current organisation but I may be missing something. If there are issues it's best to get them out in the open so we can work on fixing them.
Perhaps he is refering to Alexandre... You know, like Linus, he doesn't scale. I don't see that as a problem for quite some time though.
--tim
On Mon, 5 Sep 2005 20:30, Francois Gouget wrote:
What makes you say that? What would need changing to efficiently accomodate more developpers?
I should preface this by saying that I don't mean any criticism or offence by this. You asked the question and the following reflects my observations of current limits to the development model and what would have to be changed to improve scalability. That doesn't mean the model has not served well thus far or with the available pool of developers to date.
Having to pipe all the changes through one person limits scalability. Until recently the facilities didn't even exist for supporting the maximum scalability using that model (distributed branching), and even though they exist now few people are using them and they are not integrated into the central commit process.
Even as things are now there is a disincentive to new developers. Some developers don't bother submitting patches because they feel it's too much work to get them accepted, and sometimes the patch doesn't get written at all because there is not enough certainty that it will be accepted. Before you suggest that this is speculative, I have one developer here who has made patches to fix Wine bugs experienced at home and not submitted them for that exact reason. You can try getting guidance on what is likely to be accepted, but again you run into a bandwidth problem with Alexandre - one person cannot effectively give guidance to everybody who needs it, and such guidance as he is able to give doesn't always help that much. The process requires that developers risk their work amounting to nothing because it won't be accepted. How many times have you seen people say that "Alexandre doesn't always know what he wants, but he knows what he doesn't want"?. That perception is partly due to the fact that it is impossible for one person to take the time to really understand what is wanted for every area of Wine that is being worked on at any one time (humans are linear, it limits them).
I suspect the current model is either at or near its limits. It would certainly not cope with a significant number of commercial outfits putting in a serious level of contribution, nor does it encourage them to make the attempt.
To scale better you would need to divide the project into different areas of responsibility and have multiple committers. You could have overall guidelines, but you'd need to be willing to trust the managers of each area to make final decisions in that area - even so far as to let them make mistakes and let them learn from those mistakes. Almost every subdirectory of "dlls" could in principle be a separate area of responsibility with a separate group of committers, although it might be more convenient to have more-or-less related subdirectories under the umbrella of a single group. Each group responsible for an area would need to be prepared to give advice to people working on some patch in that area that if followed would make it virtually certain that the patch would be accepted.
A supporting facility you would probably need would likely include either separate mailing lists for each sub-project (things get lost in wine-devel *now*) with consolidated read-only lists for people who want a convenient way of watching all of the discussions or a shift to an NNTP heirarchy with mailing gateways.
These structures are nothing new - most of the really big projects work this way - look at Gnome, KDE, and for the insane end of the scale, Debian.
Even with the Linux kernel, which is the only project that I am aware of that is comparable in size and follows a similar model to Wine, there appears to me to be some greater division of responsibility.
This is all relevant, of course, only *if* significant expansion of the pool of developers is a desirable goal.
Troy Rollo wrote:
The process requires that developers risk their work amounting to nothing because it won't be accepted. How many times have you seen people say that "Alexandre doesn't always know what he wants, but he knows what he doesn't want"?.
That's a problem vitaly and I now have, ntoskrnl can run kernel mode drivers just fine (Ok, it has for months but only recently it's started using real device handles), but Alexandre doesn't like some things about it and doesn't have any alternative solutions, so we're sort of stuck with 4100 lines of working code, but no immediate prospect of getting them committed. Also I've recently noticed that very few of the patches being submitted are being committed, mainly because Alexandre appears to be *very* busy with some work (mac support maybe?), so dependencies of ntoskrnl that could go in now are still pending approval, the result is development isn't as fast as it could be because we aren't sure what to do next, have no indication of what really needs to be changed in our code, and we have to wait several days to know if what little we have submitted is ok, and when you've got loads of patches that depend on each other that is a bit of an issue.
Ivan.
On Tue, 6 Sep 2005 09:59, Ivan Leo Puoti wrote:
committed. Also I've recently noticed that very few of the patches being submitted are being committed, mainly because Alexandre appears to be *very* busy with some work (mac support maybe?),
He may well be very busy with something else, but at this stage there is also the 0.9 deadline looming, which, doing things by the book, prevents high risk patches from going in. This is something that could be alleviated with branches, but CVS branching is, by today's standards, ugly and cumbersome.
The area you are working in is of course something that Alexandre would likely keep in his area even in the event of delegation of parts, but with delegation of other areas he would hopefully have more time to consider the options for moving your stuff forward.
"Troy Rollo" wine@troy.rollo.name wrote:
Even as things are now there is a disincentive to new developers. Some developers don't bother submitting patches because they feel it's too much work to get them accepted,
Right, if the patch is a pure hack, or of a bad quality, it won't be accepted. If you insists, that that should not be an obstacle for accepting patches, or even that the patches can be committed without review and approval, then you don't understand something.
and sometimes the patch doesn't get written at all because there is not enough certainty that it will be accepted. Before you suggest that this is speculative, I have one developer here who has made patches to fix Wine bugs experienced at home and not submitted them for that exact reason.
That's not Alexandre's problem at all. You blame him, that he doesn't accept patches of poor quality, or doing wrong things, or not properly tested.
You can try getting guidance on what is likely to be accepted, but again you run into a bandwidth problem with Alexandre - one person cannot effectively give guidance to everybody who needs it, and such guidance as he is able to give doesn't always help that much.
That's why we have wine-devel. If in doubt, or need a guidance - ask there, not blame Alexandre that you don't know how to fix a bug, or implement an API, that's simply not professional.
The process requires that developers risk their work amounting to nothing because it won't be accepted.
This is true for any other project as well.
How many times have you seen people say that "Alexandre doesn't always know what he wants, but he knows what he doesn't want"?.
Not true. Alexandre almost always tells everyone that Wine needs to behave like Windows does, and if in doubt - implement it the same way as in Windows. The only problem which arises with that aproach is that we often don't know how some functionality is done in low level in Windows. Alexandre sometimes doesn't know either, but that's not the reason to blame him for that.
That perception is partly due to the fact that it is impossible for one person to take the time to really understand what is wanted for every area of Wine that is being worked on at any one time (humans are linear, it limits them).
That's a pure speculation, I won't say more.
On Tue, 6 Sep 2005, Troy Rollo wrote: [...]
Having to pipe all the changes through one person limits scalability.
This is far from being an issue with the current number of patches. By the time it becomes an issue I'm sure we'll have switched to a distributed repository model with different maintainers for each part of Wine. But you also have to realise that expecting to have multiple Wine maintainers right now is unrealistic due to lack of volunteers with enough time and who would be here for the long haul.
The only issue is when he takes a vacation but that's not very often.
[...]
Even as things are now there is a disincentive to new developers. Some developers don't bother submitting patches because they feel it's too much work to get them accepted, and sometimes the patch doesn't get written at all because there is not enough certainty that it will be accepted.
Whatever the project or development model there is the risk that the patch will have to be reworked before it can be accepted. It's necessary to ensure the quality of the code and in order for the project to move forward rather than collapse repeatedly like a badly planned building.
[...]
How many times have you seen people say that "Alexandre doesn't always know what he wants, but he knows what he doesn't want"?.
Hmmm, one? But it's unfair to expect him to solve everyone else's problems. One does not need commit access to suggest solutions to the current day's problem and when he is presented with a good solution Alexandre is quite able to say that he likes it. Otherwise you just have to accept that nobody knows what the right solution is. Then the only solution is to try one out to see if it is workable, then another one and so on until you find one that sticks. That's very much the development model of the Linux kernel btw.
[...]
I suspect the current model is either at or near its limits. It would certainly not cope with a significant number of commercial outfits putting in a serious level of contribution, nor does it encourage them to make the attempt.
I can assure you that there are many more important factors that might dissuade a company from getting involved in Wine besides 'it's hard to get patches committed'. The saying 'Whatever you do, don't compete against Microsoft' would be one for instance.
[...]
To scale better you would need to divide the project into different areas of responsibility and have multiple committers.
Well, we already have different committers for Wine, the website and the application database. But again it's the finding volunteers with the required knowledge, skill and free time that is going to be a problem.
Almost every subdirectory of "dlls" could in principle be a separate area of responsibility with a separate group of committers, although it might be more convenient to have more-or-less related subdirectories under the umbrella of a single group.
I mostly agree here. Actually I think we could easily have 2 or 3 developpers per dll or group of dlls which means we could have many more developpers without having them step on each other's toes too much. Once we get to that level of development we'll see if Alexandre becomes the bottleneck but we are very far off.
Each group responsible for an area would need to be prepared to give advice to people working on some patch in that area that if followed would make it virtually certain that the patch would be accepted.
Having more people give advice and help new contributors would certainly help. But the people giving advice don't need commit access to do that. Some developpers like Mike McCormack and Dmitry Timoshkov have been quite active in this area and I think they had a positive effect. All that's needed is subscribing to wine-devel and wine-patches, some Wine experience and the time plus the will to review patches.
A supporting facility you would probably need would likely include either separate mailing lists for each sub-project (things get lost in wine-devel *now*) with consolidated read-only lists for people who want a convenient way of watching all of the discussions or a shift to an NNTP heirarchy with mailing gateways.
I don't think there is too much traffic on wine-devel yet. At this point I feel that splitting up wine-devel runs a much greater risk to dilute discussions and extinguish them because of lack of participants. The number of emails without an answer would certainly rise.
[...]
Even with the Linux kernel, which is the only project that I am aware of that is comparable in size and follows a similar model to Wine, there appears to me to be some greater division of responsibility.
The Linux kernel is a much bigger project that Wine. I count almost 5 million lines of C code versus less than 2 million for Wine. They also have many more contributors. Just as a comparison, the lkml gets twice as much email in a week as wine-devel in a month!
This is all relevant, of course, only *if* significant expansion of the pool of developers is a desirable goal.
Yes, it definitely is. So the conclusion (mine anyway) is: * we need more volunteers to review patches and provide suggestions for improving them * we need more volunteers to help and maybe even informally 'mentor' new developpers * we need all Wine contributors to realise they should not wait for Alexandre to solve Wine's architectural problems or set directions * we could probably advertise more for Wine in universities and Linux user groups by making presentations/demos
On Tuesday 06 September 2005 19:20, Francois Gouget wrote:
On Tue, 6 Sep 2005, Troy Rollo wrote: [...]
Having to pipe all the changes through one person limits scalability.
This is far from being an issue with the current number of patches. By the time it becomes an issue I'm sure we'll have switched to a distributed repository model with different maintainers for each part of Wine. But you also have to realise that expecting to have multiple Wine maintainers right now is unrealistic due to lack of volunteers with enough time and who would be here for the long haul.
The only issue is when he takes a vacation but that's not very often.
<lots of stuff deleted for brevity>
I must disagree, the LOTM (Lord Of The Manor) governance model may work for an small outfit but wine has already outgrown it. I have two or three withheld patches which are absolute show stoppers for running wine under Solaris. They are withheld despite the fact they work because they were refused, yet every second week I am forced to work around some portability problem introduced by someone else - not exactly ISO9001 quality assurance. This causes problems for both me and the wine project because:
1. wine is NOT as portable as it should be. 2. I am forced to become the LOTM for wine under Solaris since I am currently the only source (I know of) for Solaris wine.
There must have been half a dozen times where I have decided to abandon the wine project due to its governance model, only to be encouraged back to it by my customers. These days I submit my patches to comply with the LGPL, and if they go in all well and good, if not I no longer care... Is this how developers should be thinking about wine ?
It's also important to remember that many developers that contribute (Including myself) are volunteers, volunteers are hard to come by, but really easy to get rid of. You need a governance model that is not only fair and even handed with people, but is SEEN TO BE fair and even handed. This model is not that.
Bob
On Tue, Sep 06, 2005 at 09:58:03PM +1000, Robert Lunnon wrote: ...
I must disagree, the LOTM (Lord Of The Manor) governance model may work for an small outfit but wine has already outgrown it. I have two or three withheld patches which are absolute show stoppers for running wine under Solaris. They are withheld despite the fact they work because they were refused, yet every second week I am forced to work around some portability problem introduced by someone else - not exactly ISO9001 quality assurance. This causes problems for both me and the wine project because:
- wine is NOT as portable as it should be.
- I am forced to become the LOTM for wine under Solaris since I am currently
the only source (I know of) for Solaris wine.
There must have been half a dozen times where I have decided to abandon the wine project due to its governance model, only to be encouraged back to it by my customers. These days I submit my patches to comply with the LGPL, and if they go in all well and good, if not I no longer care... Is this how developers should be thinking about wine ?
It's also important to remember that many developers that contribute (Including myself) are volunteers, volunteers are hard to come by, but really easy to get rid of. You need a governance model that is not only fair and even handed with people, but is SEEN TO BE fair and even handed. This model is not that.
Do you mailinglist posting URLs for the refusals?
You should push your patches more often and request feedback if they are rejected. Like we all do for our patches.
Portability problems need to be pointed out by more people and fixed by the contributors.
Changing the WINE development model would not help in your case.
Personally I consider the WINE project fair in its patch acceptance policies.
Ciao, Marcus
Marcus Meissner wrote:
Personally I consider the WINE project fair in its patch acceptance policies.
IMHO it's also fair to call it Wine and not WINE, IIRC this was agreed on before.
Ivan.
On Tue, 6 Sep 2005, Robert Lunnon wrote:
On Tuesday 06 September 2005 19:20, Francois Gouget wrote:
On Tue, 6 Sep 2005, Troy Rollo wrote: [...]
Having to pipe all the changes through one person limits scalability.
[...]
I must disagree, the LOTM (Lord Of The Manor) governance model may work for an small outfit but wine has already outgrown it. I have two or three withheld patches which are absolute show stoppers for running wine under Solaris. They are withheld despite the fact they work because they were refused,
So you're saying that Alexandre is wrong to refuse your patches, not that he is overloaded and drops patches so often that it limits Wine's growth.
Then adding more committers would not help. (unless you play one committer against the other to get your patches accepted)
The way forward is to dig up the patches that were rejected, post them to wine-devel with the reason that was given for their rejection (because you asked why they were rejected, right?), and ask for suggestions on how to make them more acceptable.
yet every second week I am forced to work around some portability problem introduced by someone else - not exactly ISO9001 quality assurance.
I don't see a way around that. Only users of a given platform can detect compatibility or compilation problems with that platform. We cannot expect Alexandre, or every single committer in a multi-committer system, to test on every single platform out there before each commit. Even on Linux we sometimes get compilation problems with weird libxml libraries, opengl issues, old compilers, new compilers, etc.
I'll grant you that we could possibly setup a TinderBox type of system but I feel that would be very overkill right now and even TinderBox can only detect problems after patches get committed.
Hello,
On 9/6/05, Francois Gouget fgouget@free.fr wrote:
I'll grant you that we could possibly setup a TinderBox type of system but I feel that would be very overkill right now and even TinderBox can only detect problems after patches get committed.
I don't know if everyone follows wine-cvs everyday and examines every patch that goes through but we could suggest in our documentation that CC's of patches are sent to certain developers along with wine-patches. Basically the model would stay the same as it is now except we would be laying the ground work for the move to a maintainer model. If someone wants to be a maintainer then they would add themselves to the list and would agree to review patches people to send them.
If I was going to to do some DirectX hacking I would be more inclined to send my patch to Oliver first rather than sending it to Julliard because 1) I know Oliver is the defacto maintainer right now and 2) If he has uncommitted patches in his tree then my changes could result in conflict or duplication of work.
I know it has to be frustrating for new developers that join the project don't know who works on what. They spend X amount of time working on something only to see it be rejected or to be told "You did this wrong". Sure they should have asked on wine-devel but maybe if we had a list of people that were the point of contact for certain modules (And clearly document the submission process) it would encourage them to ask more questions directly.
Thanks Steven
--- Steven Edwards winehacker@gmail.com wrote:
Hello,
On 9/6/05, Francois Gouget fgouget@free.fr wrote:
I'll grant you that we could possibly setup a TinderBox type of system but I feel that would be very overkill right now and even TinderBox can only detect problems after patches get committed.
I don't know if everyone follows wine-cvs everyday and examines every patch that goes through but we could suggest in our documentation that CC's of patches are sent to certain developers along with wine-patches. Basically the model would stay the same as it is now except we would be laying the ground work for the move to a maintainer model. If someone wants to be a maintainer then they would add themselves to the list and would agree to review patches people to send them.
If I was going to to do some DirectX hacking I would be more inclined to send my patch to Oliver first rather than sending it to Julliard because 1) I know Oliver is the defacto maintainer right now and 2) If he has uncommitted patches in his tree then my changes could result in conflict or duplication of work.
I know it has to be frustrating for new developers that join the project don't know who works on what. They spend X amount of time working on something only to see it be rejected or to be told "You did this wrong". Sure they should have asked on wine-devel but maybe if we had a list of people that were the point of contact for certain modules (And clearly document the submission process) it would encourage them to ask more questions directly.
If you send the patches in to wine-patches then I will help you get the patches applied, that may mean that they don't get committed initially and I have to work with you to get the patches to a good level of completeness. I initially had a lot of patched declined, hell it was annoying, and my work would have made it into winecvs a lot faster if they had been committed earlier, but I think breaking patches down into small, defined manageable chunks is far more important in the long run, especially if it causes regression.
Anyhow, I'm sure that all patches are very much appreciated by everyone, anyone who has any difficulty getting any patches committed should just ask for some help on wine-devel and I'm sure someone will be willing to help them out (If not just Email me and I'll give you a hand!).
Roles seem to change a lot, so I'm not sure that appointing anyone is a good idea (appart from the default maintainer of for categories of bugs), you can always look at the code or http://www.winehq.org/site/status and find whoever has submited the recient changes, it may be initially daunting but I'm sure everyone's glad someone lends a hand.
Oliver.
Thanks Steven
___________________________________________________________ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
Firstly , we are talking about a governance model here, not an individual. Read on...
On Tuesday 06 September 2005 23:26, you wrote:
On Tue, 6 Sep 2005, Robert Lunnon wrote:
On Tuesday 06 September 2005 19:20, Francois Gouget wrote:
On Tue, 6 Sep 2005, Troy Rollo wrote: [...]
Having to pipe all the changes through one person limits scalability.
[...]
I must disagree, the LOTM (Lord Of The Manor) governance model may work for an small outfit but wine has already outgrown it. I have two or three withheld patches which are absolute show stoppers for running wine under Solaris. They are withheld despite the fact they work because they were refused,
So you're saying that Alexandre is wrong to refuse your patches, not that he is overloaded and drops patches so often that it limits Wine's growth.
Then adding more committers would not help. (unless you play one committer against the other to get your patches accepted)
The way forward is to dig up the patches that were rejected, post them to wine-devel with the reason that was given for their rejection (because you asked why they were rejected, right?), and ask for suggestions on how to make them more acceptable.
I don't think so... I have provided the best solutions from an outcome point of view consistent with my (un)willingness to undertake months of work, or increase my maintenance load for little benefit. This simply reflects that Alexandre's value system is different from mine. The result is a stalemate. and shows that the project simply can't demand this of developers, it can only encourage, that's what's wrong, the encouragement isn't there....
but... The issue isn't about Alexandre, it's about a governance model that revolves around the opinion of a single person and whether the difficulty of having a patch moved forward is inhibiting the take up of developers. The proponents of this thread say yes, the governance model inhibits progress. Lets keep it at this level. I use my Solaris "core functionality patches" only to substantiate the argument that there are outstanding patches that inhibit the takeup (progress) of wine in the market. Interestingly even codeweavers has such patches that Jeremy White terms "Proprietary Advantage". This'd be good for me if I was making a living off Wine like codeweavers are. In fact perhaps I'd go out of my way to produce patches that wouldn't be accepted.
yet every second week I am forced to work around some portability problem introduced by someone else - not exactly ISO9001 quality assurance.
I don't see a way around that. Only users of a given platform can detect compatibility or compilation problems with that platform. We cannot expect Alexandre, or every single committer in a multi-committer system, to test on every single platform out there before each commit. Even on Linux we sometimes get compilation problems with weird libxml libraries, opengl issues, old compilers, new compilers, etc.
I'll grant you that we could possibly setup a TinderBox type of system but I feel that would be very overkill right now and even TinderBox can only detect problems after patches get committed.
I think you miss my point, this sort of code gets into Wine every day. Wine is already very linux centric and possibly getting more so. There's even talk of integrating Wine with the linux kernel. To me this is because the patch acceptance is not objective enough. Wine should have stated criteria for patch acceptance EG:
Functionality, Portability, Precision - EG precise windows like behaviour Form. Implementation.
in my opinion in this order
Alexandre favours precision, and implementation over functionality and portability which makes it much harder for developers to get patches accepted because developers have to guess the right implementation and get the semantics exactly right before it'll go in. It's the wrong approach to encourage a group of volunteers in my opinion. Remember the project has no inherent right to demand a participant change a patch, it will only succeed in this endeavour if it can command the loyalty of the participants. Loyalty comes from the value the project places on the individual participant. Chicken and egg situation, you need to make it easy enough to get patches through, in order to make the participant loyal enough to act on your demands for changes.
I'll go this much further and propose what I'd like to see in a governance model.
Value all developers equally regardless of race sex capability or newbieness Developer rights based on contribution Opinions valued and considered even if they are dissenting Tolerance of mistakes - Value all contributions successful or not Consistent objective assessment of submissions according to an objective outcome focused set of criteria by the community (Peer assessment), feedback of assessment for all submissions. Governance board elected by the community/stakeholders. Customer focus.
can it be done, yes, I think so.
Bob
PS - A good look at an online solaris man page would find most the problems I come across - http://docs.sun.com
takeup (progress) of wine in the market. Interestingly even codeweavers has such patches that Jeremy White terms "Proprietary Advantage". This'd be good for me if I was making a living off Wine like codeweavers are. In fact perhaps I'd go out of my way to produce patches that wouldn't be accepted.
Just so we're clear - the use of the word "Proprietary Advantage" is an inside joke. It usually refers to code that is so bad that there is no chance Alexandre would accept it into WineHQ. But there are often grey areas as well, where we get frustrated that Alexandre won't accept a patch into Wine. Our preference has been and continues to be that everything we do go into Wine first; that's the only way we get the peer review that can make Wine work well.
But I have generally found that Alexandre's instincts are quite good. He's also very reasonable; I've never found him unwilling to discuss an issue, and I think I've even managed to change his mind on occasion.
Isn't there a saying that goes something like: "The best form of government is a benevolent dictatorship... so long as you have the right dictator?"
However, I admit to a certain bias; it may be that Alexandre cottons to my interest (Linux, mainstream apps), and that there are communities that he serves badly.
But the best way to persuade me (and others) of that is to highlight the patches. Show me patches you've submitted, along with arguments for them, and persuade me that he has been wrong to refuse them.
Cheers,
Jeremy
On Thu, 8 Sep 2005 04:42, Jeremy White wrote:
But the best way to persuade me (and others) of that is to highlight the patches. Show me patches you've submitted, along with arguments for them, and persuade me that he has been wrong to refuse them.
I said I wouldn't comment further, but I think several people have completely missed the point.
The issue is not that patches get rejected. It is that in many cases there are many reasonable ways to implement any given thing, but only a subset of those will be accepted. This is particularly the case with any significant new development, and "do it the way windows does it" is not always the right answer, particularly if what you are implementing is Winelib related since Alexandre actually prefers things not directly dependent on Windows be "right" within his interpretation of "right" rather than consistent with what would be done if Microsoft were implementing the thing. *Nobody* but the person approving commits is going to be able to give reliable guidance on which of several different approaches to take in order to produce work that will be committed, except in the most trivial case. Where that is limited to one person, there are inherent limits to scalability.
Scalability is not boolean. You do not reach a particular point where it breaks, rather things deteriorate gradually at first, then at an increasing rate as you approach breaking point. As things deteriorate, the value perceived by new developers decreases.
Isolated volunteers who have already committed to the project and are prepared to accept these limitations are unlikely to see the problem. Volunteers who are not prepared to accept the limitations are unlikely to be heard at all because they will drop Wine and move on to other projects. Codeweavers tends to fall more into the dedicated volunteer category because that is where it sources its developers. Neither Robert nor I are entirely volunteers though, so there are other factors operating on our decisions.
If I were solely a volunteer I would have ceased contributing to Wine since I have other projects I can be more productive on, and Robert has indicated his similar position. That would be my position even though I believe that aside from the Linux kernel, Wine is the single most strategically important open source software development project in existence.
It should not make us happy that other projects are as bad or worse at scaling if there is the possibility of improvement. However if other projects of similar size (or greater) are better, then that is likely demonstrative of the possibility of improvement.
Is progress good? Yes. Could it be better? That is the question. Would this require a sacrifice to quality? Only if you believe Alexandre is infallible and that nobody else could competently shoulder any of his load - which raises the question of what happens if he encounters the proverbial bus. But nobody is infallible - not you, not I, not Alexandre. And I believe there are a number of people around here who could competently shoulder some of the load. That does not mean they have to make the *same* decision as Alexandre, just that they need to be making decisions that are within a legitimate range an acceptable proportion of the time.
Allow me to remind people of the original trigger for this discussion.
On Mon, 5 Sep 2005 06:24, Alex Tanner wrote:
If all the companies worked together on a single WinXP-Pro-emulating flavour of Wine, the manpower problem would be solved.
I responded:
Not really. Firstly there is not (yet) enough commercial interest in contributing to Wine development to provide the manpower, although that is changing.
Secondly, even if there were sufficient manpower, the way the Wine project is currently structured would prevent the manpower from being used efficiently.
On Mon, 5 Sep 2005 20:30, Francois Gouget wrote:
What makes you say that? What would need changing to efficiently accomodate *more* developpers?
(emphasis mine)
I responded, inter alia:
This is all relevant, of course, only *if* significant expansion of the pool of developers is a desirable goal.
Excuse the top posting, yes, this is exactly my point.
On Thursday 08 September 2005 11:02, Troy Rollo wrote:
On Thu, 8 Sep 2005 04:42, Jeremy White wrote:
But the best way to persuade me (and others) of that is to highlight the patches. Show me patches you've submitted, along with arguments for them, and persuade me that he has been wrong to refuse them.
I said I wouldn't comment further, but I think several people have completely missed the point.
The issue is not that patches get rejected. It is that in many cases there are many reasonable ways to implement any given thing, but only a subset of those will be accepted. This is particularly the case with any significant new development, and "do it the way windows does it" is not always the right answer, particularly if what you are implementing is Winelib related since Alexandre actually prefers things not directly dependent on Windows be "right" within his interpretation of "right" rather than consistent with what would be done if Microsoft were implementing the thing. *Nobody* but the person approving commits is going to be able to give reliable guidance on which of several different approaches to take in order to produce work that will be committed, except in the most trivial case. Where that is limited to one person, there are inherent limits to scalability.
Scalability is not boolean. You do not reach a particular point where it breaks, rather things deteriorate gradually at first, then at an increasing rate as you approach breaking point. As things deteriorate, the value perceived by new developers decreases.
Isolated volunteers who have already committed to the project and are prepared to accept these limitations are unlikely to see the problem. Volunteers who are not prepared to accept the limitations are unlikely to be heard at all because they will drop Wine and move on to other projects. Codeweavers tends to fall more into the dedicated volunteer category because that is where it sources its developers. Neither Robert nor I are entirely volunteers though, so there are other factors operating on our decisions.
If I were solely a volunteer I would have ceased contributing to Wine since I have other projects I can be more productive on, and Robert has indicated his similar position. That would be my position even though I believe that aside from the Linux kernel, Wine is the single most strategically important open source software development project in existence.
It should not make us happy that other projects are as bad or worse at scaling if there is the possibility of improvement. However if other projects of similar size (or greater) are better, then that is likely demonstrative of the possibility of improvement.
Is progress good? Yes. Could it be better? That is the question. Would this require a sacrifice to quality? Only if you believe Alexandre is infallible and that nobody else could competently shoulder any of his load - which raises the question of what happens if he encounters the proverbial bus. But nobody is infallible - not you, not I, not Alexandre. And I believe there are a number of people around here who could competently shoulder some of the load. That does not mean they have to make the *same* decision as Alexandre, just that they need to be making decisions that are within a legitimate range an acceptable proportion of the time.
Allow me to remind people of the original trigger for this discussion.
On Mon, 5 Sep 2005 06:24, Alex Tanner wrote:
If all the companies worked together on a single WinXP-Pro-emulating flavour of Wine, the manpower problem would be solved.
I responded:
Not really. Firstly there is not (yet) enough commercial interest in contributing to Wine development to provide the manpower, although that is changing.
Secondly, even if there were sufficient manpower, the way the Wine project is currently structured would prevent the manpower from being used efficiently.
On Mon, 5 Sep 2005 20:30, Francois Gouget wrote:
What makes you say that? What would need changing to efficiently accomodate *more* developpers?
(emphasis mine)
I responded, inter alia:
This is all relevant, of course, only *if* significant expansion of the pool of developers is a desirable goal.
On Thu, 8 Sep 2005, Robert Lunnon wrote: [...]
The issue isn't about Alexandre, it's about a governance model that revolves around the opinion of a single person and whether the difficulty of having a patch moved forward is inhibiting the take up of developers.
I think this governance model can work as long as the 'gardian' of the source has the required competence, experience and vision.
And I think Alexandre has all these qualities. Despite you saying this is not about Alexandre you must be of a differing opinion since you are not happy with the current situation as your arguments about the 'Solaris core functionality patches' show.
But an hypothetical committee aproach won't help an hypothetical set of patches get through unless a solid majority of the committee is in favor of that set of patches.
[...]
Interestingly even codeweavers has such patches that Jeremy White terms "Proprietary Advantage".
Yes CrossOver has ugly application-specific hacks that happen to help one of the supported applications but may well break a 100 non-supported applications. And yes Alexandre won't let CodeWeavers commit these patches to Wine. And yes, he is right to reject such patches since they are not correct (i.e. don't conform to Windows behavior).
[...]
I think you miss my point, this sort of code gets into Wine every day. Wine is already very linux centric and possibly getting more so.
And what practical measure are you proposing to avoid this?
I don't see how a multi-committer model is going to help. All you need is one Linux-using committer to commit a patch to break things for all others. The only way to avoid this would be to require approval by all committers before a patch actually gets committed which does not seem practical or likely to speed up acceptance of patches.
[...]
Functionality, Portability, Precision - EG precise windows like behaviour Form. Implementation.
In the following I'll assume Functionality to mean 'percentage of working Windows applications'. The more traditional interpretation would be to equate it with features but that's probably not what you meant.
Either way, trading precision for more functionality is not a good move. It means introducing bugs, in order to hide other bugs so now you have two set of bugs. Except the hidden bugs will now bite you when you don't expect and without you realising what has bitten you which makes debugging and thus progress harder. So 'Precision' should be at the very top.
It's also my opinion that portability should be before functionality. That is functionality can be added only so long as it does not prevent portability. That's why Wine has all these autoconf checks and even runtime checks so one binary can work on most systems inside a given platform.
And if I'm right to understand Implementation to mean Maintainability, and Form to refer to the indentation and so on, then Maintainability should come before Formatting. That's not to say I'm not annoyed by some of the weird formatting of some source files but maintainability has more of an impact on the ability to make the project move forward (and one can also argue that the nastiest forms formatting are part of the maintainability issue anyway so that all that remains to formatting is the minor issues).
I'd add features to the list, as in various options, bells and whisles, etc. This should go after Maintainability. That's because while bells and whisles are nice, killing maintainability will ensure the project stagnates.
So my own list would look something like this:
Windows Conformance (was Precision) Portability Functionality Maintainability (was Implementation) Features Formatting
I think it matches the Wine project priorities.
[...]
Remember the project has no inherent right to demand a participant change a patch,
This is true. Just as true as the following:
The participant as no right to demand that the project accept his patch.
The relationship between a project and a volunteer is a *mutually* *consensual* one.
it will only succeed in this endeavour if it can command the loyalty of the participants. Loyalty comes from the value the project places on the individual participant.
Indiscriminately accepting patches is not a workable way for a project to move forward. Building a project like Wine is like building a wall where each volunteer contributes one or more 'bricks'. Now if you start accepting not just genuine bricks but also pieces of wood, shoe boxes, lego bricks, plastic boxes and any other material brought by the volunteers your wall is soon going to collapse. And that will set the whole project back, possibly forcing a very costly redesign, throwing away much code, etc.
Indiscriminately accepting patches will not buy you loyalty. Wisdom in choosing which patches should go in and which need to be reworked will buy you respect and loyalty.
On Thursday 08 September 2005 10:11, Francois Gouget wrote:
On Thu, 8 Sep 2005, Robert Lunnon wrote: [...]
The issue isn't about Alexandre, it's about a governance model that revolves around the opinion of a single person and whether the difficulty of having a patch moved forward is inhibiting the take up of developers.
I think this governance model can work as long as the 'gardian' of the source has the required competence, experience and vision.
And I think Alexandre has all these qualities. Despite you saying this is not about Alexandre you must be of a differing opinion since you are not happy with the current situation as your arguments about the 'Solaris core functionality patches' show.
No, I'm not, but I respect his right under the prevailing governance to refuse them even though I don't buy in to his decision, just as Alexandre has to accept that I have little intention of changing them to suit him. One day when I have a week or so free, I might, you never know.
But an hypothetical committee aproach won't help an hypothetical set of patches get through unless a solid majority of the committee is in favor of that set of patches.
[...]
This isn't the point either, if you have a commitee structure or multiple maintainers then you almost must have a process for establishing architecture and for submission assessment which is objective otherwise you can't get consistent approach to architecture. As we have seen different people put the attributes I listed in different orders, personally for example I'd commit a functionality patch that wasn't portable (Properly #ifdefed for the platform and with a fixme for others) to promote emulation of that function on others.
Now I'm not saying here that Alexandre isn't objective, just that his criteria of assessment is not clear to me, and after 2 years doing this I still reckon I have about a 50/50 chance of having anything major accepted. If it's not clear to me, then it must be positively opaque to someone new. You might say that the project is open, but the governance is closed in that the developer and user communities have little influence over governance.
I see this as a bad thing.
To get some feel for what I'm suggesting have a look at the OpenSolaris model. Direction is set by a Community Advisory Board, soon to be replaced by a Governance Board which comprises both Sun and community representatives. OpenSolaris is struggling with some of the development model issues now but are proposing escalation procedures for developer disputes to the Architecture review boards. Though summary (no-escalation) models are also being proposed, I don't personally favour them because they don't give developers the confort that they've had a fair hearing or that the "majority has spoken"
See here for more detail on decisions, it's not perfect but not too bad
.http://www.opensolaris.org/jive/thread.jspa?threadID=1344&tstart=15
Anyway, I've said enough, my opinions on governance are pretty clear
Bob
Robert Lunnon wrote:
takeup (progress) of wine in the market. Interestingly even codeweavers has such patches that Jeremy White terms "Proprietary Advantage". This'd be good for me if I was making a living off Wine like codeweavers are. In fact perhaps I'd go out of my way to produce patches that wouldn't be accepted.
It works both ways. If you choose the "unmergable" option, you'll soon find that you're not able to merge the Wine community's contributions back into your tree...
Mike
The only reason I had not made some of these comments earlier was that I knew that they would not be well received, and that there would be at least some unconstructive responses. A prerequisite for having a productive discussion of this kind is being able to recognise the possible validity of alternative points of view, and to be aware of and have the maturity to accept the reality that nobody is infallible and in any particular instance it may be you who is wrong, and to react appropriately when it turns out you were wrong. There are some people here who can do that, and others who cannot. Unfortunately the ones who are not are usually the loudest and tend to destroy any value in the discussion.
I always find it particularly amusing when people try to tell me what a commercial organisation in a particular situation would do when I'm a person who makes the particular type of decision concerned in a commercial organisation.
I do not intend to fully respond to the replies. I did not expect the discussion to go anywhere productive (and still don't). I only made my detailed comments because I was asked directly based on a deliberately vague comment that I thought would not be controversial. I am at least not surprised by the complete lack of any attempt to be constructive on the part of one participant (who, for avoidance of doubt, is not one of the people quoted below).
Nevertheless, two new points have been raised that merit some type of comment.
On Tue, 6 Sep 2005 21:58, Robert Lunnon wrote:
by my customers. These days I submit my patches to comply with the LGPL, and if they go in all well and good, if not I no longer care... Is this how
This is not necessary to comply with the LGPL, not is it even a possible element in ensuring compliance.
On Tue, 6 Sep 2005 23:26, Francois Gouget wrote:
The way forward is to dig up the patches that were rejected, post them to wine-devel with the reason that was given for their rejection (because you asked why they were rejected, right?), and ask for suggestions on how to make them more acceptable.
This of course points to another problem with the existing system - if a patch has been rejected, it should be a necessary consequence that the submitter is informed with reasons - they shouldn't have to be chasing up Alexandre to find out if the patch was rejected or merely missed (which happens often). This is not to criticise Alexandre, but to point out that systems need to be put in place to help him manage these things. Just taking patches of the mailing list is not a sufficient mechanism. What is needed is a system that records all patches, together with their current status (NEW, APPLIED, REJECTED (with reasons), and whatever other status), informs the submitter of any change, and does not allow for a patch merely to be forgotten.
The present system leads to inevitable delays since the submitter has to wait a while until it seems likely that the patch is not going to go in, then ask why - if submitters received immediate feedback once there is a decision, they could turn around a new version of the patch much more quickly (and an ideal system would link the new submission to the original to put it in more complete context). Then others who may be depending on the patch can get on with their work too.
It ought to help Alexandre too since it would mean he wouldn't have to try to remember a week later why he rejected a particular patch, or re-examine the patch to figure out what he was thinking.
It may be that Bugzilla could be coaxed into this role, although I suspect it's not particularly well adapted to this core task without some customisation.
This of course points to another problem with the existing system - if a patch has been rejected, it should be a necessary consequence that the submitter is informed with reasons - they shouldn't have to be chasing up Alexandre to find out if the patch was rejected or merely missed (which happens often). This is not to criticise Alexandre, but to point out that systems need to be put in place to help him manage these things. Just taking patches of the mailing list is not a sufficient mechanism. What is needed is a system that records all patches, together with their current status (NEW, APPLIED, REJECTED (with reasons), and whatever other status), informs the submitter of any change, and does not allow for a patch merely to be forgotten.
We actually have a todo on Jeremy Newman's list to build a patch management system for wine-devel, for Alexandre.
Our hope was that we could adopt some of the CodeWeavers systems (we have a ticket system that's pretty slick, for example).
However, it became clear that the requirements were fairly substantial (the tight emacs integration became our first clue :-/), and that project got back burnered.
At the time we were discussing that, though, we didn't have many volunteer web programmers; maybe we should revisit that. Alexandre, would you be interested if folks other than Jer volunteered to help build such a system?
With that said, I have to ask - what open source projects are you guys working on that don't suffer from these problems? I'm now a successful contributor to the Linux Kernel (tweaked isofs for Windows CDs) and it took me 3 years and countless dropped emails, despite the personal help of Alan Cox and Andrew Morton before my patch got in (and I have another patch, a minor bug fix, that I despair will ever see the light of day). I had a similar situation with MythTV (and the #mythtv channel is actively hostile to anyone mildly clueless), and the list goes on.
Based on my experiences, I would say that Wine is a cut above, and Alexandre does a very fine job.
On the other hand, I've often thought that the developer section should have a big FAQ to help explain how Alexandre works (notably the fact that he uses the absolute minimum amount of communication required at any time) <grin>.
Cheers,
Jeremy
Jeremy White jwhite@codeweavers.com writes:
At the time we were discussing that, though, we didn't have many volunteer web programmers; maybe we should revisit that. Alexandre, would you be interested if folks other than Jer volunteered to help build such a system?
Sure, I don't really care who builds it, as long as I can use it from inside Emacs <g>
Jeremy White wrote:
We actually have a todo on Jeremy Newman's list to build a patch management system for wine-devel, for Alexandre.
Our hope was that we could adopt some of the CodeWeavers systems (we have a ticket system that's pretty slick, for example).
However, it became clear that the requirements were fairly substantial (the tight emacs integration became our first clue :-/), and that project got back burnered.
At the time we were discussing that, though, we didn't have many volunteer web programmers; maybe we should revisit that. Alexandre, would you be interested if folks other than Jer volunteered to help build such a system?
Jeremy, I think that's a great idea and the appdb improvements clearly show the web guys could come up with something really good.
Ivan.
This of course points to another problem with the existing system - if a patch has been rejected, it should be a necessary consequence that the submitter is informed with reasons - they shouldn't have to be chasing up Alexandre to find out if the patch was rejected or merely missed (which happens often). This is not to criticise Alexandre, but to point out that systems need to be put in place to help him manage these things. Just taking patches of the mailing list is not a sufficient mechanism. What is needed is a system that records all patches, together with their current status (NEW, APPLIED, REJECTED (with reasons), and whatever other status), informs the submitter of any change, and does not allow for a patch merely to be forgotten.
I've always thought that sort of thing should be done and would be cool, maybe the guys working on appdb could try and come up with something?
Troy Rollo wrote:
What is needed is a system that records all patches, together with their current status (NEW, APPLIED, REJECTED (with reasons), and whatever other status), informs the submitter of any change, and does not allow for a patch merely to be forgotten.
Absolutely!
Bugzilla can make this process better (so not perfect). However all would be very transparent and manageable for the maintainer(s). I think, there is some serious food for thought here....
It may be that Bugzilla could be coaxed into this role, although I suspect it's not particularly well adapted to this core task without some customisation.
Regards
Signer: Eddy Nigg Company: StartCom Linux at www.startcom.org http://www.startcom.org/ MediaHost^(TM) at www.mediahost.org http://www.mediahost.org/ Skype: startcom callto://startcom/ Phone: +1.213.341.0390
Import StartCom Public CA http://cert.startcom.org/index.php?app=109
[...]
I suspect the current model is either at or near
its limits. It would
certainly not cope with a significant number of
commercial outfits putting in
a serious level of contribution, nor does it
encourage them to make the
attempt.
I can assure you that there are many more important factors that might dissuade a company from getting involved in Wine besides 'it's hard to get patches committed'.
As a user, I've been particularly happy about how Wine has progressed. However, what is of GRAVE concern to me is when patches that fix serious bugs aren't applied; specifically, bug 3148. Even the patch submitter had to plead with this alias for someone to listen because no one was paying attention to the patch. Yet, to date, the patch has either not been applied nor the bug been fixed. Simple, yet silly, bugs like the beforementioned one can keep users from taking advantage of newer versions of Wine because they prefer to stay with older versions that don't have the bug(s).
Food for thought...
Hiji
______________________________________________________ Click here to donate to the Hurricane Katrina relief effort. http://store.yahoo.com/redcross-donate3/
"Hiji" hijinio@yahoo.com wrote:
As a user, I've been particularly happy about how Wine has progressed. However, what is of GRAVE concern to me is when patches that fix serious bugs aren't applied; specifically, bug 3148. Even the patch submitter had to plead with this alias for someone to listen because no one was paying attention to the patch. Yet, to date, the patch has either not been applied nor the bug been fixed.
Do you or the author of the patch know why the patch has not been accepted? Did you or he ask about the reason? If the patch was rejected because it's wrong or of a poor quality, Wine CVS with multiple committers would not solve this particular problem.
--- Dmitry Timoshkov dmitry@baikal.ru wrote:
"Hiji" hijinio@yahoo.com wrote:
As a user, I've been particularly happy about how
Wine
has progressed. However, what is of GRAVE concern
to
me is when patches that fix serious bugs aren't applied; specifically, bug 3148. Even the patch submitter had to plead with this alias for someone
to
listen because no one was paying attention to the patch. Yet, to date, the patch has either not
been
applied nor the bug been fixed.
Do you or the author of the patch know why the patch has not been accepted? Did you or he ask about the reason? If the patch was rejected because it's wrong or of a poor quality, Wine CVS with multiple committers would not solve this particular problem.
I don't want to speak for the author directly, but last I checked, no one would even acknowledge that the patch was submitted - so it didn't even reach the rejection or acceptance point. The sad part is that the patch that created the bug was accepted, but after realizing the error of the first patch, the author tried to submit a second patch to fix his first error. Thus, that leads us to where we are at now.
This is my understanding of the situation.
Hiji
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Hiji hijinio@yahoo.com writes:
As a user, I've been particularly happy about how Wine has progressed. However, what is of GRAVE concern to me is when patches that fix serious bugs aren't applied; specifically, bug 3148. Even the patch submitter had to plead with this alias for someone to listen because no one was paying attention to the patch. Yet, to date, the patch has either not been applied nor the bug been fixed. Simple, yet silly, bugs like the beforementioned one can keep users from taking advantage of newer versions of Wine because they prefer to stay with older versions that don't have the bug(s).
That patch was applied 2 weeks ago.
--- Alexandre Julliard julliard@winehq.org wrote:
Hiji hijinio@yahoo.com writes:
As a user, I've been particularly happy about how
Wine
has progressed. However, what is of GRAVE concern
to
me is when patches that fix serious bugs aren't applied; specifically, bug 3148. Even the patch submitter had to plead with this alias for someone
to
listen because no one was paying attention to the patch. Yet, to date, the patch has either not
been
applied nor the bug been fixed. Simple, yet
silly,
bugs like the beforementioned one can keep users
from
taking advantage of newer versions of Wine because they prefer to stay with older versions that don't have the bug(s).
That patch was applied 2 weeks ago.
Great! Thanks for acknowledging this. I'll wait for the September release because the August release produced the same bug(s).
Thank you, Hiji
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Tue, Sep 06, 2005 at 09:26:44AM +1000, Troy Rollo wrote:
To scale better you would need to divide the project into different areas of responsibility and have multiple committers.
Well, one can say that this model already exists implicitely as most patches to 'non-core' DLLs (DirectX in my case) are applied without much problem by Alexandre (as long as no other DirectX 'core' hackers do not complain when the patch is sent to wine-patches).
Now one could say that it would be better to have direct commit access for one guy, but well, it never really hurt anyone (and frankly, I prefer to have the Alexandre quality control as it oftens helps us finding bugs or better solutions if not the basic stuff to force people to send 'small' patches :-) ).
Lionel
Alex Tanner wrote:
I can't understand why the members of the Wine project are always complaining about lack of manpower. The lack of manpower is probably due to there being different flavours of Wine developed by different companies.
[...]
I think you overestimate the real number of Wine forks out there. At CodeWeavers we contribute back all our Wine patches with very few exceptions. See the wine-patches mailing list and look for patches from '@codeweavers.com' to see what I mean. So really all our work directly benefits Wine and reciprocally we do weekly imports of the Wine tree so that we do not duplicate the work done by the Wine community. So it's very synergistic there.
And I am sure that all other Wine contractors and companies but one also work on the standard WineHQ sources and make sure their patches get promptly integrated into the main tree. Besides, Wine being LGPL, there is a garantee that the source for any forked tree will be available so we can pick patches and merge them with the main tree.
-
Alex Tanner -
Alexandre Julliard -
Dmitry Timoshkov -
Evil -
Francois Gouget -
Francois Gouget -
Hiji -
Ivan Leo Puoti -
Jeremy White -
Kuba Ober -
Lionel Ulmer -
Marcus Meissner -
MediaHost (TM) -
Mike Hearn -
Mike McCormack -
Oliver Stieber -
Robert Lunnon -
Steven Edwards -
Tim Schmidt -
Troy Rollo