There was a discussion here about 2 months ago, where I asked for a way to embed WINE config strings into Win32 executable (for example, as string resources). I was told that it is better to fix the problem rather than to create workarounds, and that fixing bugs is trivial and takes at most 2-3 days as soon as it is reproducible.
I didn't argue much then but made a little experiment to prove my point. The point is the following: THE MOST DIFFICULT THING IN GETTING BUG FIXED IS TO GET SOMEBODY WORK ON IT. The same applies both to commercial environments and to open source ones equally. Experiment illustrates it very well:
I've found an application that experiences the problem with sympthoms which are very similar to ours, can be installed in 5 minutes and the problem can be reproduced in 3 clicks. And I've opened a bug in WINE's bugzilla: #3270 (another one #3269 was opened for another incompatibility). Result is the following: IN 6 WEEKS NOBODY EVEN TOOK A LOOK AT BOTH THOSE BUGS.
Welcome to the real world
_________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
On Thu, Oct 13, 2005 at 06:12:02PM +0000, John Smith wrote:
There was a discussion here about 2 months ago, where I asked for a way to embed WINE config strings into Win32 executable (for example, as string resources). I was told that it is better to fix the problem rather than to create workarounds, and that fixing bugs is trivial and takes at most 2-3 days as soon as it is reproducible.
I didn't argue much then but made a little experiment to prove my point. The point is the following: THE MOST DIFFICULT THING IN GETTING BUG FIXED IS TO GET SOMEBODY WORK ON IT. The same applies both to commercial environments and to open source ones equally. Experiment illustrates it very well:
I've found an application that experiences the problem with sympthoms which are very similar to ours, can be installed in 5 minutes and the problem can be reproduced in 3 clicks. And I've opened a bug in WINE's bugzilla: #3270 (another one #3269 was opened for another incompatibility). Result is the following: IN 6 WEEKS NOBODY EVEN TOOK A LOOK AT BOTH THOSE BUGS.
Welcome to the real world
Yes, we welcome you to the wonderful world of OpenSource.
Please understand that a lot of us are not being paid ... and so just chose what to do. Some of us are paid to work on WINE, but for specific tasks.
So your bug might lie around until someone bothers to look at it. Or not if it is tickling the interest of a developer.
#3270 ... is difficult, since it is lowlevel USER stuff. #3269 ... Not hard, its just that no one implemented it yet.
Please do not keep up such high expectations, they are not warranted and will not be fulfilled.
Ciao, Marcus
Hi, [...]
Welcome to the real world
Yes, we welcome you to the wonderful world of OpenSource.
Please understand that a lot of us are not being paid ... and so just chose what to do. Some of us are paid to work on WINE, but for specific tasks.
So your bug might lie around until someone bothers to look at it. Or not if it is tickling the interest of a developer.
#3270 ... is difficult, since it is lowlevel USER stuff. #3269 ... Not hard, its just that no one implemented it yet.
Please do not keep up such high expectations, they are not warranted and will not be fulfilled.
Or hire a wine developer to specifically work on those tasks ,-)
Yours,
Yes, we welcome you to the wonderful world of OpenSource.
Or hire a wine developer to specifically work on those tasks ,-)
Hmmm... Out of 4 replies I've seen now 3 (or 75%) were about money. Which leads to the question - why _that_ many people in the wonderful world of OpenSource are obsessed with money?
From: René Rebe rene@exactcode.de To: wine-devel@winehq.org CC: Marcus Meissner marcus@jet.franken.de, John Smith devel8421@hotmail.com Subject: Re: Reality check Date: Thu, 13 Oct 2005 22:58:41 +0200
Hi, [...]
Welcome to the real world
Yes, we welcome you to the wonderful world of OpenSource.
Please understand that a lot of us are not being paid ... and so just
chose
what to do. Some of us are paid to work on WINE, but for specific tasks.
So your bug might lie around until someone bothers to look at it. Or not if it is tickling the interest of a developer.
#3270 ... is difficult, since it is lowlevel USER stuff. #3269 ... Not hard, its just that no one implemented it yet.
Please do not keep up such high expectations, they are not warranted and will not be fulfilled.
Or hire a wine developer to specifically work on those tasks ,-)
Yours,
-- René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany) http://www.exactcode.de | http://www.t2-project.org +49 (0)30 255 897 45
_________________________________________________________________ On the road to retirement? Check out MSN Life Events for advice on how to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement
John Smith wrote:
Yes, we welcome you to the wonderful world of OpenSource.
Or hire a wine developer to specifically work on those tasks ,-)
Hmmm... Out of 4 replies I've seen now 3 (or 75%) were about money. Which leads to the question - why _that_ many people in the wonderful world of OpenSource are obsessed with money?
Hey, I'm a student, I'm broke, why should I ever work on anything other that what I think would be interesting/fun/cool to do?
Ivan.
On 10/14/05, John Smith devel8421@hotmail.com wrote:
Hmmm... Out of 4 replies I've seen now 3 (or 75%) were about money. Which leads to the question - why _that_ many people in the wonderful world of OpenSource are obsessed with money?
John, you really need to chill out.
Free Software works like this: The programmers scratch their own itches. That's it! Users who have an itch not shared by any programmer have no right to complain. Don't look a gift horse in the mouth, as they say. If you *really* want a bug fixed, and no programmer is willing to fix it for free, and you can't fix it yourself, you have two choices: 1) wait for some programmer to decide he wants to fix it for his own reasons 2) pay a programmer to do it for you.
I'm a huge fan of Free Software and open source in general; I've been writing it for twenty years now. I'm not some money-obsessed person. I put in lots of time QA'ing Wine, maintaining crosstool, and enhancing distcc. Part of this is on my own time because I want to see it happen, and part of it is because my employer needs features (in e.g. crosstool or distcc). People like me and like the Codeweavers folks who are working our hearts out to advance Wine really do *not* need to hear users pout because their favorite bug isn't being fixed immediately. (Users like that remind me of that girl in Willy Wonka and the Chocolate Factory.)
OK., enough ranting for now. Further complaints about wine development to /dev/null, please.
Hi,
On Friday 14 October 2005 16:00, John Smith wrote:
Yes, we welcome you to the wonderful world of OpenSource.
Or hire a wine developer to specifically work on those tasks ,-)
Hmmm... Out of 4 replies I've seen now 3 (or 75%) were about money. Which leads to the question - why _that_ many people in the wonderful world of OpenSource are obsessed with money?
Nope we are not - and this is why we do it just for fun or because we need one or the other thing.
It also means you can do it just for the fun or because you need the feature, or hire someone if you need something urgently.
Yours,
John Smith wrote:
Hmmm... Out of 4 replies I've seen now 3 (or 75%) were about money. Which leads to the question - why _that_ many people in the wonderful world of OpenSource are obsessed with money?
If you want to boss people round and complain when people don't spend their time fixing bugs you're interested in, you should be paying money.
Mike
Please do not keep up such high expectations, they are not warranted and will not be fulfilled.
Isn't it too high to expect that before answering somebody will read original posting? Once again: originally I didn't have any expectations, but tried to suggest a generic workaround for different kind of bugs (those that can be fixed by tweaking configuration parameters like infamous Managed=N). And was told "c'm on, the biggest problem in fixing the bug is to reproduce it". Well, it has been proven not to be the case.
See also parts of the original discussion here: ========================================== http://wiki.jswindle.com/index.php/WineLib#Using_the_Registry_to_alter_Winec... "S. Shemesh: If you give a scenario that is easilly reproduceable, it is rare that problems go more than a couple of days unfixed." "All we are saying is "pin-point the problem for us". ==========================================
"More than a couple of days"? Do "6 weeks" qualify?
From: Marcus Meissner marcus@jet.franken.de To: John Smith devel8421@hotmail.com CC: wine-devel@winehq.org Subject: Re: Reality check Date: Thu, 13 Oct 2005 22:41:11 +0200
On Thu, Oct 13, 2005 at 06:12:02PM +0000, John Smith wrote:
There was a discussion here about 2 months ago, where I asked for a way
to
embed WINE config strings into Win32 executable (for example, as string resources). I was told that it is better to fix the problem rather than
to
create workarounds, and that fixing bugs is trivial and takes at most
2-3
days as soon as it is reproducible.
I didn't argue much then but made a little experiment to prove my point. The point is the following: THE MOST DIFFICULT THING IN GETTING BUG FIXED IS TO GET SOMEBODY WORK ON
IT.
The same applies both to commercial environments and to open source ones equally. Experiment illustrates it very well:
I've found an application that experiences the problem with sympthoms
which
are very similar to ours, can be installed in 5 minutes and the problem can be reproduced in 3 clicks. And I've opened a bug in WINE's bugzilla: #3270 (another one #3269 was opened for another incompatibility). Result is the following: IN 6 WEEKS NOBODY EVEN TOOK
A
LOOK AT BOTH THOSE BUGS.
Welcome to the real world
Yes, we welcome you to the wonderful world of OpenSource.
Please understand that a lot of us are not being paid ... and so just chose what to do. Some of us are paid to work on WINE, but for specific tasks.
So your bug might lie around until someone bothers to look at it. Or not if it is tickling the interest of a developer.
#3270 ... is difficult, since it is lowlevel USER stuff. #3269 ... Not hard, its just that no one implemented it yet.
Please do not keep up such high expectations, they are not warranted and will not be fulfilled.
Ciao, Marcus
_________________________________________________________________ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Please do not keep up such high expectations, they are not warranted and will not be fulfilled.
[...]
Once again: originally I didn't have any expectations, but tried to suggest a generic workaround for different kind of bugs (those that can be fixed by tweaking configuration parameters like infamous Managed=N). And was told "c'm on, the biggest problem in fixing the bug is to reproduce it". Well, it has been proven not to be the case.
That was said assumed that when the bug is reproduceable, someone will like to fix it. Duh, I'd say. What else did you expect? Does everything have to be spelled out these days?
Cheers, Kuba
If you want the bug fixed urgently, pay someone to do so.
John Smith wrote:
There was a discussion here about 2 months ago, where I asked for a way to embed WINE config strings into Win32 executable (for example, as string resources). I was told that it is better to fix the problem rather than to create workarounds, and that fixing bugs is trivial and takes at most 2-3 days as soon as it is reproducible.
I didn't argue much then but made a little experiment to prove my point. The point is the following: THE MOST DIFFICULT THING IN GETTING BUG FIXED IS TO GET SOMEBODY WORK ON IT. The same applies both to commercial environments and to open source ones equally. Experiment illustrates it very well:
I've found an application that experiences the problem with sympthoms which are very similar to ours, can be installed in 5 minutes and the problem can be reproduced in 3 clicks. And I've opened a bug in WINE's bugzilla: #3270 (another one #3269 was opened for another incompatibility). Result is the following: IN 6 WEEKS NOBODY EVEN TOOK A LOOK AT BOTH THOSE BUGS.
Welcome to the real world
FREE pop-up blocking with the new MSN Toolbar – get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
John Smith wrote:
THE MOST DIFFICULT THING IN GETTING BUG FIXED IS TO GET SOMEBODY WORK ON IT.
If your business depends upon getting a Wine bug fixed, then you should pay somebody to work on the problem. There are several companies (including the one I work for) that can do this for you.
Mike
If your business depends upon getting a Wine bug fixed, From my perspective, the only thing that depends upon getting a Wine bug
fixed, is making Wine a decent competitor to Windows on desktop in, say, 3 years (let's be optimistic).
including the one I work for) that can do this for you.
BTW, you might be able to clarify how it can happen that Crossover (derived from LGPL-ed WINE, if I understand it correctly) doesn't have one of these bugs, but WINE does? I used to think that LGPL requires availability of modified source, and therefore WINE developers should be able to 'backport' bugfixes from CrossOver to WINE, shouldn't they?
From: Mike McCormack mike@codeweavers.com To: John Smith devel8421@hotmail.com CC: wine-devel@winehq.org Subject: Re: Reality check Date: Fri, 14 Oct 2005 08:57:02 +0900
John Smith wrote:
THE MOST DIFFICULT THING IN GETTING BUG FIXED IS TO GET SOMEBODY WORK ON IT.
If your business depends upon getting a Wine bug fixed, then you should pay somebody to work on the problem. There are several companies (including the one I work for) that can do this for you.
Mike
_________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
BTW, you might be able to clarify how it can happen that Crossover (derived from LGPL-ed WINE, if I understand it correctly) doesn't have one of these bugs, but WINE does? I used to think that LGPL requires availability of modified source, and therefore WINE developers should be able to 'backport' bugfixes from CrossOver to WINE, shouldn't they?
John,
This page: http://www.codeweavers.com/products/source/ takes two clicks to get to from our home page, and has all of our public source code, including Wine.
We also have a company policy that prefers that all the work we do on Wine is publicly submitted to wine-devel first, before we commit to our own tree.
I think Dan answered your email quite well, but I wanted to add an additional thought for others reading:
Money is not the only answer. It helps, and it tends to be the only choice for pushy and rude people.
But I have found that, on many open source projects, it is possible to get help from a developer. It takes an enormous amount of effort, a great deal of politeness, and some luck. But most open source developers are actually quite giving. The keys, imho, are:
1. Do your homework
Read the FAQs. Read the ML archives. Actually try the various alternatives suggested. Research the technical issues at hand. Learn enough so you know what you're talking about.
Do that first.
2. Make it easy
Developers find a nice bug report, with easy to follow instructions to reproduce, and nice easy access to the software to be quite nice.
3. Ask nicely
If you want someone to work for you, for free, you have to recognize that they are giving you a gift - a gift of their time.
If you can't hold that in mind when you ask, then you're not asking right.
Cheers,
Jeremy
- Ask nicely
This is key, and I completely agree.
However, there is a more fundamental problem here. I don't see "bugs" in a black vs. white type of view; in fact, I can classify bugs in two ways: 1) A bug is something that has always been broken 2) A bug is something that is broken, but it once worked
When it comes to #1, I say, "Yes, ask nicely. Hopefully, someone will step up to fix it. If you need to, pay someone to fix it."
When it comes to #2, I say, "Explain nicely. You broke something which once worked; you caused this bug. Fix it. It's the right thing to do. Don't expect to get paid for something you broke."
And of my biggest concerns about the growth of Wine, it's always been about #2. First, it was Photoshop7 which worked perfectly (and from what I understand, Disney poured money into getting this to work), but then someone broke its ability to run for close to a year; no one stepped up to fix what got broken. ("Success" popup window, anyone?) Now, it's about bug 3148 which magically showed up after December of 2004; aside from Vitaliy who was kind enough to look into it, no one has stepped up to say, "whoops! Sorry, I seem to have broken that by accident. I will try to get that fixed." Even something as simple as an acknowledgement will help ease the situation.
Do I want to pay someone to fix something that they broke? Absolutely not. That's like having someone say, "I will wash your house windows for free." You say, "ok." Then, they break your windows by accident, won't fix them, and then say, "If you want, you can pay me to fix your windows."
Is it is the right and responsible thing to do for someone to step up and fix bugs that they cause? Absolutely yes. Open source or not. Absolutely yes.
Hiji
__________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
On Fri, Oct 14, 2005 at 09:50:48AM -0700, Hiji wrote:
However, there is a more fundamental problem here. I don't see "bugs" in a black vs. white type of view; in fact, I can classify bugs in two ways:
- A bug is something that has always been broken
- A bug is something that is broken, but it once
worked
This is still too 'white and black'. What about a patch that fixes 1) and in the process introduces 2) (case in point the WM rewrite and windowed GL applications) ?
Lionel
--- Lionel Ulmer lionel.ulmer@free.fr wrote:
On Fri, Oct 14, 2005 at 09:50:48AM -0700, Hiji wrote:
However, there is a more fundamental problem here.
I
don't see "bugs" in a black vs. white type of
view; in
fact, I can classify bugs in two ways:
- A bug is something that has always been broken
- A bug is something that is broken, but it once
worked
This is still too 'white and black'. What about a patch that fixes 1) and in the process introduces 2) (case in point the WM rewrite and windowed GL applications) ?
I think that still falls into #2, and that's pretty much my point.
Analogy: I need an oil change. I take my car to the car shop. They do the oil change. They also return my car with a flat tire that it didn't have before. I know it could be an accident, but the responsible thing to do is for the car shop to fix that flat tire.
Besides, without this type of "responsibility" in place, I could theoretically pay a developer to fix a bug for me, and then, 3 months down the line, some other developer breaks it. What do I do then? Pay money again to have someone refix it?
Hiji
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Besides, without this type of "responsibility" in place, I could theoretically pay a developer to fix a bug for me, and then, 3 months down the line, some other developer breaks it. What do I do then? Pay money again to have someone refix it?
If you think that a newer version of Wine is "broken" for the application you are interested in, then you can always go back to the older version of Wine where it worked.
Nobody magically made it so that you *have* to upgrade. If you made it work before, then it's possible to make it work again, isn't it? If you forgot what combination of software worked, is that really my problem?
If your app worked in Wine 200104xx with Redhat 7, then you can still make it install that and make it work :)
Now if somebody changes something in an attempt to improve things, and you want their improvements, and you want your old applications to work, then you want something from them, don't you?
Mike
Besides, without this type of "responsibility" in place, I could theoretically pay a developer to fix a bug for me, and then, 3 months down the line, some other developer breaks it. What do I do then? Pay money again to have someone refix it?
Additionally, you might want to read this part of the LICENSE file again:
"This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details."
Mike
Additionally, you might want to read this part of the LICENSE file again:
"This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details."
Of course I'm familiar with that. I'm not saying anything at all about Wine's warranty. What I am talking about is about the general sense of responsibility. Money or not. Fixing what you broke is the right thing to do -- regardless of the disclaimer.
And yet, presenting that disclaimer almost defeats the argument to pay for bug fixing; again, I could theoretically pay for development to fix a bug which could end up broken again in 3 months.
Nobody magically made it so that you *have* to upgrade.
Magic? No. Progress? Yes, I have to because of this. What do I mean? I have been using wine-20041201 until I upgraded to opensuse 10.0; the compile won't succeed now. Otherwise, I would have stuck with that old version.
Now, take a different look on things and try to recall how often people tell users, "Why are you on such an old version of Wine? You should be using a newer version."
If you made it work before, then it's possible to make it work again, isn't it? If you forgot what combination of software worked, is that really my problem?
I think you're steering far away from the point I was making about responsibility. ;) Far FAAAR away. I don't screw around with DLL overrides (perhaps just for experimenting), and I don't even use wine-tools. If something breaks, it's definately not because I can't remember a combination of hacks I did - simply because, I didn't do this.
Now if somebody changes something in an attempt to improve things, and you want their improvements, and you want your old applications to work, then you want something from them, don't you?
In the context of this example and referring to what I'm getting at, you get one improvement, but in return, something else gets broken. That just doesn't seem right. It's like the little kid who makes breakfast for mom & dad, but in the process, makes a mess of the kitchen (that mom & dad end up having to clean up anyways).
And really, in the grand scheme of things, I'm not writing all of this because of what *I* want for myself. I'm writing this because I really DO care about Wine, I'm a big supporter of it, and I want it to succeed ... I'm hoping that this will cause some light bulbs to turn on and bring some realizations to light.
You guys are probably sitting on the most valuable API of this era, and it drives ABSOLUTELY nutz that many people here don't even realize this. And when people pop out these disclaimers as an excuse for not fixing things, it adds salt to the wounds. If I could get in there to code, I would do so, but I can't. And, all I can do from this corner of the ring is cheer on Wine and bring to the table non-technical issues which clearly get in the way of its progression.
Peace & Love for Wine!! :) Hiji
__________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
Hiji wrote:
In the context of this example and referring to what I'm getting at, you get one improvement, but in return, something else gets broken. That just doesn't seem right. It's like the little kid who makes breakfast for mom & dad, but in the process, makes a mess of the kitchen (that mom & dad end up having to clean up anyways).
You keep refering to things in the real world like broken windows, broken down cars and physical mess, but software isn't like that, it's an idea, and can't be destroyed, or broken, only added to.
What you're paying people to do is to add, improve, refine and maintain. You can clean up the mess done by any patch just by doing:
patch -p0 -R < dodgy.diff
Hmm... but maybe you need my help to identify with is dodgy.diff, even though I didn't write that patch? ;)
I like fixing stuff, but I don't have much patience for people telling me that I *must* and then wanting it done for free.
Peace & Love for Wine!! :) Hiji
here here :)
Mike
Friday, October 14, 2005, 9:17:19 PM, Hiji wrote:
Additionally, you might want to read this part of the LICENSE file again:
"This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details."
Of course I'm familiar with that. I'm not saying anything at all about Wine's warranty. What I am talking about is about the general sense of responsibility. Money or not. Fixing what you broke is the right thing to do -- regardless of the disclaimer.
I think you need to look at EULA as well. If the product itself that Wine tries to emulate does not guarantee anything. What do you expect from poor open-source copy of it? <g>
Vitaliy
--- Vitaliy Margolen wine-devel@kievinfo.com wrote:
What do you expect from poor open-source copy of it?
<g>
To help the Wine community realize that even though it is poor, it is stronger than it thinks. I truely see Wine as the David in the Goliath world of Microsoft - and Linux is the stone. (Or is Linux the David, and Wine the stone?) ;)
Hiji
__________________________________ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/
responsibility. Money or not. Fixing what you broke is the right thing to do -- regardless of the disclaimer.
Actually, there is an important point being overlooked here that deserves being brought out.
Wine regresses all the time. Any decent programmer worth her salt would be embarrased to work on a finished product that regressed all the time. Yet I think we are blessed with many decent programmers on the Wine project.
So that's why Wine is officially labeled 'Alpha' software. It's labeled as such, in recognition by the developers of Wine that fundamental pieces of the puzzle are not yet done correctly, and that future breakage is likely.
So, for example, years ago we had no process separation. Lots of programs worked because cross process messaging 'worked'. Of course, lots of others failed to work, because their memory space was corrupted. Now we fixed this, so suddenly lots of applications stopped working. A regression? From a user perspective, yes. The right thing to do? Absolutely.
The good news is the whole point of the 0.9 release is to mark the turning point where we shift out of Alpha and towards 'Beta'.
In other words, the supposedly decent programmers now think regressions will happen less frequently, and will purportedly take them more seriously in the future. <grin>
Cheers,
Jeremy
If you want someone to work for you, for free,
I don't. In fact, I don't care about those bugs at all. Once again (for the 3rd time, BTW): I just tried to make Wine a little bit more compatible with 3rd-party applications (by supporting a way for Win programmers to specify WINE config parameters within executable). I was told that it doesn't make sense, as 'bugs are usually fixed within 2-3 days', which I had serious doubts about (it just doesn't work that way), so I've made a little experiment. I was right, you guys were wrong, and now you're trying to blame me? I don't really think that after all that heated conversation somebody is going to consider my original proposal, but frankly I don't care about WIne anymore - I definitely don't like this 'pay me' attitude (rather than normal 'sorry, we didn't have time to fix it yet' attitude).
you have to recognize that they are giving you a gift - a gift of their time.
Come on, with this attitude we won't get anywhere. I'm also spending my time reporting the bugs I don't really care about (except generic 'making Wine better'). We are all in the same boat, and on other open source projects (the one I'm working on - on my own, not employer time, BTW - included) reported bugs are treated as a help from the users, not with 'pay me to fix it' attitude.
_________________________________________________________________ On the road to retirement? Check out MSN Life Events for advice on how to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement
On Sat, 2005-10-15 at 13:27 +0000, John Smith wrote:
Come on, with this attitude we won't get anywhere. I'm also spending my time reporting the bugs I don't really care about (except generic 'making Wine better').
And that's appreciated. Unfortunately, Wine is very incomplete in the sense that you don't have to look far to find lots of bugs. Because of this, we don't usually have the same sense of urgency as other projects to fix them -- there is an infinite stream of them just around the corner.
Not an excuse -- I'm just trying to explain why we don't just on the bugs when they are filled in Bugzilla. Now that we have 0.9 on the way (hopefully followed by 1.0), this attitude seems to be changing.
We are all in the same boat, and on other open source projects (the one I'm working on - on my own, not employer time, BTW - included) reported bugs are treated as a help from the users, not with 'pay me to fix it' attitude.
That's a misunderstanding. I agree with you that the conversation has derailed rather sharply in that direction. However, this is not the attitude around here. It was a reaction to your perceived approach to the problem. While well intentioned, you came of as demanding stuff (bugs fixed, apologies, whatever).
It was a rough start -- it's easy to be misunderstood on mailing lists. Lets just relax and start fresh :)
As for your original proposal, the problem with it is that long term will hurt the project -- it will encourage people to work around bugs rather then help us fix them. That makes most sense for a company. We want the project to go forward, so we can not accept such a solution.
Unfortunately, Wine is very incomplete in the sense that you don't have to look far to find lots of bugs. Because of this, we don't usually have the same sense of urgency as other projects to fix them -- there is an infinite stream of them just around the corner.
Sure; that's why I was really surprised when I was told that 'usually bugs are fixed in 2 or 3 days'.
While well intentioned, you came of as demanding stuff (bugs fixed, apologies, whatever).
Nope. I tried to get attention and I succeeded with it, though this kind of 'pay me' reaction was unexpected.
As for your original proposal, the problem with it is that long term will hurt the project -- it will encourage people to work around bugs rather then help us fix them.
At least arguable. Looking from outside world, I would say that at current stage WINE needs as much 3rd-party applications as possible. If this is true, and given the (currently proven and admitted) fact that you guys do have lots of stuff to do even without additional feedback, I'd say that adding a regular workaround mechanism (with lots of disclaimers that it will be deprecated in the future) would help to increase WINE popularity as of now. In addtion, similar workarounds do exist now, but they are: a) tricky, b) irregular, c) undocumented.
From: Dimi Paun dimi@lattica.com To: John Smith devel8421@hotmail.com CC: jwhite@codeweavers.com, wine-devel@winehq.org Subject: Re: Reality check Date: Sat, 15 Oct 2005 09:59:51 -0400
On Sat, 2005-10-15 at 13:27 +0000, John Smith wrote:
Come on, with this attitude we won't get anywhere. I'm also spending my time reporting the bugs I don't really care about (except generic 'making Wine better').
And that's appreciated. Unfortunately, Wine is very incomplete in the sense that you don't have to look far to find lots of bugs. Because of this, we don't usually have the same sense of urgency as other projects to fix them -- there is an infinite stream of them just around the corner.
Not an excuse -- I'm just trying to explain why we don't just on the bugs when they are filled in Bugzilla. Now that we have 0.9 on the way (hopefully followed by 1.0), this attitude seems to be changing.
We are all in the same boat, and on other open source projects (the one I'm working on - on my own, not employer time, BTW - included) reported bugs are treated as a help from the users, not with 'pay me to fix it' attitude.
That's a misunderstanding. I agree with you that the conversation has derailed rather sharply in that direction. However, this is not the attitude around here. It was a reaction to your perceived approach to the problem. While well intentioned, you came of as demanding stuff (bugs fixed, apologies, whatever).
It was a rough start -- it's easy to be misunderstood on mailing lists. Lets just relax and start fresh :)
As for your original proposal, the problem with it is that long term will hurt the project -- it will encourage people to work around bugs rather then help us fix them. That makes most sense for a company. We want the project to go forward, so we can not accept such a solution.
-- Dimi Paun dimi@lattica.com Lattica, Inc.
_________________________________________________________________ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/
-
Dan Kegel -
Dimi Paun -
Hiji -
Ivan Leo Puoti -
Jeremy White -
John Smith -
Joseph Garvin -
Kuba Ober -
Lionel Ulmer -
Marcus Meissner -
Mike McCormack -
René Rebe -
Vitaliy Margolen