Road to 1.0

[James Hawkins]

On 3/22/07, Bryan Haskins <kingofallhearts999 at gmail.com> wrote:
>
> >
> > If you are making it extremely easy for users to run with native dlls
> > and hacky workarounds, then you are hurting Wine.  Wine is still beta,
>
> That's true... and people technically should only be using wine for the pure
> sake of testing and helping fix usage. LEt's be honest, very few use it for
> that, they just want it to work, they use wine for the use the Devs want out
> of 1.0. Saying to someone that because it doesn't work by default, we're not
> going to let you use it, or in general make it hard for them defeats the
> goal of the *actual program*,
>

No one here says they can't use Wine if their app doesn't work, and
we're certainly not trying to make it harder for them if that is the
case.  The argument is irrelevant though, as it doesn't follow the
original question, "Does my development of Wine-Doors hurt Wine."

>Joe XYZ wants to play Oblivion, He Finds it
> doesn't work! He looks around and sees that if he does a lot of various
> things it will work *okay*, Joe XYZ does them. Joe XYZ had no intention of
> ever submitting bugs at all, is this bad? Hell yes it is. We should educate
> at how important it is for a program like Wine to have nice detailed Bug
> Tracking, but at the same time, can you blame him for just wanting it to
> work, easily? As long as the user, at some point, realized, hey this doesn't
> work out of the box, the job is done to some degree.
>

The optimal outcome of this scenario is that Joe XYZ reports his
problems running Oblivion to the Wine development community using
bugzilla.  The Wine development community then fixes these bugs,
leaving Joe XYZ very satisfied with Wine.  The next possible outcome
is that it takes a little while for the bugs to be fixed, though
they'll be fixed at some point, but we do try our hardest.  If
developers working on projects such as Wine-Doors contributed to Wine,
then the bugs would be fixed even faster.

> To summarize, If a user never was going to report things, that's bad, he
> should be educated, but at the same time, if he still wouldn't, shouldn't it
> be our job as the community to make it easy for him?
>

Make it easy for him to report the bugs?  Yea we should make it as
easy as possible.

> This goes back to the WineTools thing... that was bad though, even though at
> face it seems the same... in reality people were starting to just say
> Install Wine, then you *need* to install winetools and run the base install
> thing, without ever actually saying "HEY! Newbs! This wont work so you
> should install zyx to make it work as a temporary solution until such a time
> as it's fixed in the wine tree." OR something similar.
>

Wine-Doors is the exact same thing as WineTools from the perspective
of the Wine developers.

> I guess my point is two fold:
> -The user needs to know about bug reporting.

Definitely, and we're doing a good job at it so far.

> -The user needs to know what it means for something to not work
> 'out-of-the-box', and what exactly a 'dirty little hack' or the like is.
>

Users know when things don't work out-of-the-box, whether they know
what the term means or not, and we wouldn't have to worry about a user
knowing what a 'dirty little hack' is if projects like Wine-Doors
didn't exist.

-- 
James Hawkins