p 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 <[EMAIL PROTECTED]>
To: John Smith <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED], wine-devel@winehq.org
Subject: Re: Reality
--- Vitaliy Margolen <[EMAIL PROTECTED]> wrote:
> What do you expect from poor open-source copy of it?
>
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
> 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
On Sat, 2005-10-15 at 13:27 +, 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
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 para
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 FIT
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
> 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 Gen
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
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 "bro
--- Lionel Ulmer <[EMAIL PROTECTED]> 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:
> > 1) A bug is something that
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,
> John Smith wrote:
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
> 3. 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 i
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 bu
> 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 '
> 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. Sometim
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 - wh
> >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
On 10/14/05, John Smith <[EMAIL PROTECTED]> 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 l
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 Ope
'backport'
bugfixes from CrossOver to WINE, shouldn't they?
From: Mike McCormack <[EMAIL PROTECTED]>
To: John Smith <[EMAIL PROTECTED]>
CC: wine-devel@winehq.org
Subject: Re: Reality check
Date: Fri, 14 Oct 2005 08:57:02 +0900
John Smith wrote:
THE MOST DIFFICULT
obsessed with money?
From: René Rebe <[EMAIL PROTECTED]>
To: wine-devel@winehq.org
CC: Marcus Meissner <[EMAIL PROTECTED]>, John Smith
<[EMAIL PROTECTED]>
Subject: Re: Reality check
Date: Thu, 13 Oct 2005 22:58:41 +0200
Hi,
[...]
> > Welcome to the real world
>
>
saying is "pin-point the problem for us".
==
"More than a couple of days"? Do "6 weeks" qualify?
From: Marcus Meissner <[EMAIL PROTECTED]>
To: John Smith <[EMAIL PROTECTED]>
CC: wine-devel@winehq.org
Subject: Re: Reality che
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.
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 tha
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 som
On Thu, Oct 13, 2005 at 06:12:02PM +, 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
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
29 matches
Mail list logo
