[Fwd: Wine-Wiki.org]

Francois Gouget fgouget at free.fr
Thu Jan 27 02:06:06 CST 2005

On Wed, 26 Jan 2005, Tony Lambregts wrote:

> Francois Gouget wrote:
>> On Wed, 26 Jan 2005 tony_lambregts at telusplanet.net wrote:
>> [...]
>>> As far as things go until we go to a "Stable release" system then we will 
>>> always have this problem.
>> That the problem: a "Stable Wine release" has been six months away since 
>> 1998 and even before. But we still don't have one, have no idea when there 
>> will be one and thus we should not do stuff that will only makes sense once 
>> we will have a stable release and are just confusing and meaningless until 
>> then.
> Thats BS. (pardon me) :^) That is circular reasoning. What I am hearing is we 
> shouldn't define the criteria for "stable" because we aren't stable. We could 
> go "stable" today if we wanted and this is how:

I'm not saying we cannot define the criteria, I'm saying it does not 
make sense to work and make promises today that will only make sense 
when we have stable releases which could be years away (if following 
historical trends).

And no, we cannot make 'stable' releases today. Some of the criteria for 
0.9 are: completing the window management rewrite, good enough dll 
separation and stabilizing the wineserver protocol. We're close on some 
of these goals but there's still work. And as far as I know there won't 
be stable releases before we reach 0.9.

>> Maybe this is how it will work, maybe not. It would be a big change from 
>> the way things work right now and nobody knows when this is going to happen 
>> so it's presumptuous to make predictions.
> How's that? The way it works now is that if someone reports on Wine Devel 
> that patch X breaks their application the developer of the patch usually will 
> step up with a fix, often it is the same day. I cannot see how this is in any 
> way presumptuous. It simply flows from the way we work today.

I can tell you that there are a lot of regressions that slip through and 
are only detected much later and that give us (CodeWeavers) quite a lot 
of work before doing a release. Hopefully the situation will be much 
better once cxtest is in 'full production' and Wine has more 

>> IMHO it's best to focus on the now and do stuff that makes sense now.
> Having maintainers of apps makes sense in its own right.

Yes, I agree absolutely there.

>> This should really go in a "Maintainer's Guide" somewhere.
> IIRC Its part of the sign screen up. We probably should get it such a 
> document when it is written.

I did not see it on this page:

I'd expect to see it somewhere in the 'Documentation' pages:

> If copying DLL's is OK for you why not Copying programs.

Because copying programs usually require copying parts of the Windows 
registry which I think is just way too complex for a regular user.

Usually copying a dll doesn't require anything more than copying a 
file, sometimes not even that as the dll may have already been 
installed by the application and all you need is to tell Wine to use it 
instead of the builtin.

> Also Hacks can lead 
> to good patches and don't tell you have never used a hack to get the job 
> done. AFAIAC "Perfect" means you can run it out of the box with no tweeking.

Yes, we could have a 'Works great' for apps running great with hacks and 
limit 'Perfect' to the applications that run great with only builtin 
dlls and no 'abnormal' dependencies.

>>  * Can I run it?
>>    It's a very important step. Until the application at least starts you 
>> have no idea how much stuff is broken.
> These are good for the developer but the focus of the AppDB is on the user. 
> This is where Bugzilla comes into the picture. I am working on a patch to 
> better integrate these two applications. I was planning on working on it 
> tonight but instead ended up responding to this. ;^)

The AppDB should be useful to Wine developers too.

Francois Gouget         fgouget at free.fr        http://fgouget.free.fr/
                   In a world without fences who needs Gates?

More information about the wine-devel mailing list