On Wed, 26 Jan 2005, Tony Lambregts wrote:
Francois Gouget wrote:
On Wed, 26 Jan 2005 tony_lambregts@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 maintainers.
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: http://appdb.winehq.org/account.php?cmd=new
I'd expect to see it somewhere in the 'Documentation' pages: http://appdb.winehq.org/help/
[...]
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.