Reality check

Reality check

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.

Re: Reality check

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.

Re: Reality check

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.

Re: Reality check

> 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/>
>
>
>

Re: Reality check

>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_Winecfg"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 <[hidden email]>
>To: John Smith <[hidden email]>
>CC: [hidden email]>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

Re: Reality check

> > 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 <[hidden email]>
>To: [hidden email]>CC: Marcus Meissner <[hidden email]>, John Smith
><[hidden email]>
>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

Re: Reality check

>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 <[hidden email]>
>To: John Smith <[hidden email]>
>CC: [hidden email]>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

Re: Reality check

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?

Re: Reality check

On 10/14/05, John Smith <[hidden email]> 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.

Re: Reality check

> >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?

Re: Reality check

> > > 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.

Re: Reality check

> 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?

Crossover has a limited set of applications that it supports, whereas Wine
tries to support "all" applications. Sometimes a gross, ugly hack ends up
in Crossover to support an app, that would break other apps, except that
those other apps aren't supported by Crossover. As such the hacks end up
remaining in the Crossover tree, and not going into winehq.

> 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?

Re: Reality check

> 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?

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.

Re: Reality check

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.

Re: Reality check

Before y'all take this too seriously, consider the email address and the
name. "John Smith" at an anonymous hotmail account smells like a troll
to me.

>From my point of view, Wine is a godsend and the amount of work going
into it is fabulous. We at Muse Research depend on your work for our
business and are greatly appreciative. Major congratulations on getting
to the code freeze, by the way. Thanks to you all.

Sure there are bugs to fix and maybe you have to fix them yourself or
pay someone to do it. The alternative for "John" is clear: buy MS
Windows. It works pretty well.

Re: Reality check

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:
> 1) A bug is something that has always been broken
> 2) 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) ?

Re: Reality check

> 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:
> > 1) A bug is something that has always been broken
> > 2) 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

Re: Reality check

> 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?