Yea, I agree with what you said, I didn't mean for my message to sound like people were doing anything blatantly wrong, the fact is though, if we like them or hate them from a development standpoint, people love these work arounds as users, and, it's just the evolution of the community that will make things like this. For the user it's make it make it work quick, more so than get fixes into the tree. Since we can't just stop the projects, which I don't think we would *really* want to, working aorund them is the best bet. Maybe talk with the maintainers of these so called Wine GUIs, and have them implement methods of sending in reports. Not to mention that we could have some kind of an unexpected kill catch to compile bugreports automatically, and tell the user how to go about submitting it, or even do it for them, to some degree we could have information on individual fix mes sent as well, you could imagine seeing which 'fixme' was spit out the most, then focusing on it. Things like that would not only help users get to the devs, but help the devs stay on track of whats best needed, for those that focus on the general need, rather than the "this doesn't work for me, I'll fix it" way, which isn't so bad in itself.
<br><br>I don't know... I'm an idealist =]<br><br><div><span class="gmail_quote">On 3/23/07, <b class="gmail_sendername">James Hawkins</b> <<a href="mailto:truiken@gmail.com">truiken@gmail.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On 3/22/07, Bryan Haskins <<a href="mailto:kingofallhearts999@gmail.com">kingofallhearts999@gmail.com
</a>> wrote:<br>><br>> ><br>> > If you are making it extremely easy for users to run with native dlls<br>> > and hacky workarounds, then you are hurting Wine. Wine is still beta,<br>><br>> That's true... and people technically should only be using wine for the pure
<br>> sake of testing and helping fix usage. LEt's be honest, very few use it for<br>> that, they just want it to work, they use wine for the use the Devs want out<br>> of 1.0. Saying to someone that because it doesn't work by default, we're not
<br>> going to let you use it, or in general make it hard for them defeats the<br>> goal of the *actual program*,<br>><br><br>No one here says they can't use Wine if their app doesn't work, and<br>we're certainly not trying to make it harder for them if that is the
<br>case. The argument is irrelevant though, as it doesn't follow the<br>original question, "Does my development of Wine-Doors hurt Wine."<br><br>>Joe XYZ wants to play Oblivion, He Finds it<br>> doesn't work! He looks around and sees that if he does a lot of various
<br>> things it will work *okay*, Joe XYZ does them. Joe XYZ had no intention of<br>> ever submitting bugs at all, is this bad? Hell yes it is. We should educate<br>> at how important it is for a program like Wine to have nice detailed Bug
<br>> Tracking, but at the same time, can you blame him for just wanting it to<br>> work, easily? As long as the user, at some point, realized, hey this doesn't<br>> work out of the box, the job is done to some degree.
<br>><br><br>The optimal outcome of this scenario is that Joe XYZ reports his<br>problems running Oblivion to the Wine development community using<br>bugzilla. The Wine development community then fixes these bugs,<br>
leaving Joe XYZ very satisfied with Wine. The next possible outcome<br>is that it takes a little while for the bugs to be fixed, though<br>they'll be fixed at some point, but we do try our hardest. If<br>developers working on projects such as Wine-Doors contributed to Wine,
<br>then the bugs would be fixed even faster.<br><br>> To summarize, If a user never was going to report things, that's bad, he<br>> should be educated, but at the same time, if he still wouldn't, shouldn't it
<br>> be our job as the community to make it easy for him?<br>><br><br>Make it easy for him to report the bugs? Yea we should make it as<br>easy as possible.<br><br>> This goes back to the WineTools thing... that was bad though, even though at
<br>> face it seems the same... in reality people were starting to just say<br>> Install Wine, then you *need* to install winetools and run the base install<br>> thing, without ever actually saying "HEY! Newbs! This wont work so you
<br>> should install zyx to make it work as a temporary solution until such a time<br>> as it's fixed in the wine tree." OR something similar.<br>><br><br>Wine-Doors is the exact same thing as WineTools from the perspective
<br>of the Wine developers.<br><br>> I guess my point is two fold:<br>> -The user needs to know about bug reporting.<br><br>Definitely, and we're doing a good job at it so far.<br><br>> -The user needs to know what it means for something to not work
<br>> 'out-of-the-box', and what exactly a 'dirty little hack' or the like is.<br>><br><br>Users know when things don't work out-of-the-box, whether they know<br>what the term means or not, and we wouldn't have to worry about a user
<br>knowing what a 'dirty little hack' is if projects like Wine-Doors<br>didn't exist.<br><br>--<br>James Hawkins<br></blockquote></div><br><br clear="all"><br>-- <br>Cheers,<br>Bryan