[Fwd: Wine-Wiki.org]

[Francois Gouget]

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.


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

IMHO it's best to focus on the now and do stuff that makes sense now.

In a way it's just a wording issue, I would not be opposed to the notion 
of 'maintained applications'.


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


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


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


[...]
>> 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
>>   Installs
>>   Starts up
>>   Usable
>>   Perfect
>
> Any rating system sucks by definition in my book. You forgot.
>
> Does not install but if copied over from a real windows system runs 
> perfectly..
> 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 usable.
> I can apply a patch (hack) that Alexandre won't apply and then is perfect.
> 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 
Guide).

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

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

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

  * Perfect
    The application is fully usable.

That's all that matters to users.


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


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

-- 
Francois Gouget         fgouget at free.fr        http://fgouget.free.fr/
Nouvelle version : les anciens bogues ont \xE9t\xE9 remplac\xE9s par de nouveaux.