tony_lambregts at telusplanet.net
Wed Jan 26 23:57:48 CST 2005
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:
Instead of Alexandre simply saying "today" I am going to release, we do the
- Alexandre makes an announcement that CVS is in freeze.
- Maintainers of current "Gold" apps find regressions.
- Maintainers report the patchs that broke the applications.
- We fix the regressions and they are all fixed we release.
>> When we do go to a Stable release cycle I would expect that part of
>> the criteria for the next stable release would be that all "Gold"
>> applications were still "Gold".
> 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.
> 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.
> In a way it's just a wording issue, I would not be opposed to the notion
> of 'maintained applications'.
If its just semantics then fine. I did not come up with the term. IIRC it was
Dimi. We can change it if it really matters to you.
>> That would be at least one big incentive for someone to become a
>> maintainer. It is critical that the maintainers find regressions in a
>> timely manner in order to do this and without maintainers we can never
>> expect to get to wine 1.0.
> Yes, maintainers have a big role to play in helping Wine move forward
> faster and avoid regressions (by detecting them early). I'd just
> disagree about the not getting to Wine 1.0 without maintainers but
> that's not important.
All that users care is that their application works. We need a structured way of
defining what works and what does not. The application database without
maintainers could not give us that. I would not have spent as much time on it if
I thought we could do it any other way.
>> In the mean time applications are supported in the sense that someone
>> is willing to make sure that regressions are at least noted, and that
>> the entry is maintained (write a HOWTO, answer comments, provide a
>> screenshot and in the future ruport bugs).
>> The level of support that anyone can expect from any maintainer is
>> that they (the maintainer) will try to help the person get the program
>> to run.
> 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.
>> CodeWeavers does not make any guarantee that just because one version
>> of a program is supported the next will be (ie Microsoft Word).
> I have not claimed that. Nobody can garantee that because Foo 2000 works
> today, Foo 2003 will work tomorrow on the current Wine, or even on a
> future Wine in a timely manner (just add some copy protection, a useless
> driver the app will not start without, or rewrite it from scratch).
>> So if we had a stable release cycle and CodeWeavers does not change
>> their official support policy. They approach the same meaning.
> Yes but Wine does not have stable releases and nobody can say when it
> will have stable releases. So for the forseeable future they don't have
> the same meaning.
Same circular reasoning. see first comment.
>>> That's the thing with numbers (stars) and medals: it's not clear what
>>> they mean. It might be clearer to just state:
>>> Not tested
>>> Does not install
>>> Starts up
>> Any rating system sucks by definition in my book. You forgot.
>> Does not install but if copied over from a real windows system runs
>> Does not install but if copied over from a real windows system is usable.
>> I can apply a patch (hack) that Alexandre won't apply and then it will
>> start up.
>> I can apply a patch (hack) that Alexandre won't apply and then it is
>> I can apply a patch (hack) that Alexandre won't apply and then is
>> I can use sidenet and it works fine.
>> There are more ....
> No. The rating should be taken once you have taken the reasonable steps
> described in the Application Database. This includes copying some native
> dlls, installing stuff such as MSI or Internet Explorer beforehand. I
> think patches and copying from a Windows system should be ruled out
> because they are too complex (something to define in the Maintainer's
If copying DLL's is OK for you why not Copying programs. 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. There are
apps like that and I see no reason to make it less clear to the user or maintainer.
> And all that counts is the end result once you have followed these steps:
> * Can I at least install it?
> Matters to Wine developers. It translates to 'Will I be able to debug
> * 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. ;^)
> * Is it usable?
> Users want to know if they will be able to do anything with it. If
> the application is marked as Usable then yes. Maybe some functions won't
> work like printing, maybe burning CDs or other stuff like that and these
> should be listed but not everyone needs them. What counts is the core
Apps like this are Bronze and need the resources of Bugzilla to deal with them.
> * Perfect
> The application is fully usable.
> That's all that matters to users.
Those are Gold and Silver.
>> There is no way around the fact that if a program is not "Gold" or
>> "Perfect" you need a at least a HOWTO.
> Even Gold or Perfect may need a HOWTO. If you can make the application
> run 'perfectly' by using native comctl32.dll, then it should still
> deserve its 'perfect' status.
An application that requires native DLLs is not "Perfect" since I should not
need a windows licence to run Windows applications. (Yes it is harsh but we are
kidding ourselves otherwise.)
>>> As for the maintainer vs. user rating, both should use the same
>>> system since they are both doing the same thing. It's just that the
>>> maintainer rating should be given a more prominent place.
>> If it was up to me I would eliminate the the user rating. (But thats me.)
> I would not be strongly opposed to this.
We are not too far apart. I was just going with the flow when I implemented the
maintainer rating system. Gold and silver apps were already defined and it
seemed appropriate to follow that with bronze to include apps that are "Usable"
and "Garbage" for those that are seriously broke. I talked extensively on IRC
about this with Chris Morgan and others before implementing it. I admit it is
not perfect but as I have said before. Any rating system sucks by definition.
More information about the wine-devel