August 2007 - Wine-Devel - list.winehq.org

Re: Is there a process for reviewing a bugzilla staffer?

by Chris Morgan

> Rewriting: > > We can conclude that VM was distracted first by the mention of the ies4lin and > second by attempts to attribute the problem to ies4lin, and that, because of > these distractions, he was unable to assess properly the issue at hand. One > also concludes that VM over-relied on the features of the development process > automation (bugzilla) and this this was also causel to tine incident since > data available from bugzilla effectively masked the real problem. > I also wanted to mention that ies4lin SHOULD be a distraction. If users want to use unsupported tools to modify their configuration do we really want to be debugging those modifications as well as wine issues? Chris

Aug. 2, 2007

Re: Is there a process for reviewing a bugzilla staffer?

by Chris Morgan

On 8/2/07, Kuba Ober <kuba(a)mareimbrium.org> wrote: > On Wednesday 01 August 2007, Vitaliy Margolen wrote: > > Whit Blauvelt wrote: > > > Hi, > > > > > > Is there a formal process for reviewing an arguably incompetent bugzilla > > > staffer? Obviously it wouldn't be to submit their name as a bug. But is > > > there any defined administrative layer that concerns itself with people > > > on that level who are dragging on the project? > > > > > > I looked around a bit for information on this. Sorry if it's posted > > > somewhere and I missed it. > > > > > > Thanks, > > > Whit > > > > To spare everyone time and to skip directly to an entertainment see bug > > 9147: http://bugs.winehq.org/show_bug.cgi?id=9147 > > I agree with Whit. Most of your writing in that bug report would be in line > with lack of sleep or prolonged fatigue, or some other factor that causes you > to be compartmentalized in your own verions of things and completely ignore > the real issue at hand. > > Similar behavioral pattern that happened on China Airlines Flight 006. The > resemblance is striking: the pilots completely unaware of what the real > problem is, and were dealing with non-issues (rather than fluing the plane). > Similar thing here: the user tells you one thing (the real issue), your > situational awareness is as if something entirely different has been taking > place (dupes, etc). Interesting. > > http://en.wikipedia.org/wiki/China_Airlines_Flight_006 > > http://www.rvs.uni-bielefeld.de/publications/Incidents/DOCS/ComAndRep/China… > > http://catless.ncl.ac.uk/Risks/3.79.html > > [...] the captain had become so preoccupied with the dwindling > airspeed that he failed to note that the autopilot, which relied on ailerons > only, not the rudder, to maintain heading, was using the maximum left control- > wheel deflection available to it to overcome the thrust asymmetry due to the > hung outboard engine. When the right wing nevertheless began to drop, ... > the captain didn't notice the bank on the attitude indicator ... . When he > did notice it, he refused to believe what he saw. At this point, ... the > upset had begun and the captain and first officer were both spatially > disorientated. > > You can almost substitute terms from the bugreport for the flying terms > above... > > > Common thing to happen when you're tired, distracted, etc. So this is nothing > personal, just noticing a pretty common problem. BTDT, one has to learn to > recognize the first signs and take a break (helps me). At least here it won't > kill anyone. Now, if you *are* sleeping well (and long enough), and are not > tired, then IANAD and wouldn't know what to do either... > > Cheers, Kuba I've spent a fair amount of time helping users on irc in #winehq and this bug report sounds like one of the most common issues, user error precipitated by a distribution that requires a high level of user knowledge. The back and forth on the bug is mostly a waste of time trying to figure out user compile time options, which version of wine is actually running when multiple versions are installed etc. I can understand Vitaliy's frustration with this stuff as its easily avoidable on almost all binary package based distributions. Maybe we should point gentoo users at the gentoo wiki page we have and enhance that page with things we've learned from gentoo debugging. Chris

Aug. 2, 2007

Re: Is there a process for reviewing a bugzilla staffer?

by Kuba Ober

> We can conclude that VM was distracted first by the mention of the ies4lin > and second by attempts to attribute the problem to ies4lin, and that, > because of these distractions, he was unable to assess properly the issue > at hand. One also concludes that VM over-relied on the features of the > development process automation (bugzilla) and this this was also causel to > tine incident I meant 'causal to the incident'. Can't spell today, and someone turned kmail's spellchecker off (sure thing it could have been me). Cheers, Kuba

Aug. 2, 2007

Re: Is there a process for reviewing a bugzilla staffer?

by Kuba Ober

> > > Is there a formal process for reviewing an arguably incompetent > > > bugzilla staffer? > > To spare everyone time and to skip directly to an entertainment see bug > > 9147: http://bugs.winehq.org/show_bug.cgi?id=9147 > I agree with Whit. Most of your writing in that bug report would be in line > with lack of sleep or prolonged fatigue, or some other factor that causes > you to be compartmentalized in your own verions of things and completely > ignore the real issue at hand. > [...] > [...] the captain had become so preoccupied with the dwindling > airspeed that he failed to note that the autopilot, which relied on > ailerons only, not the rudder, to maintain heading, was using the maximum > left control- wheel deflection available to it to overcome the thrust > asymmetry due to the hung outboard engine. When the right wing nevertheless > began to drop, ... the captain didn't notice the bank on the attitude > indicator ... . When he did notice it, he refused to believe what he saw. > At this point, ... the upset had begun and the captain and first officer > were both spatially disorientated. > > You can almost substitute terms from the bugreport for the flying terms > above... http://www.rvs.uni-bielefeld.de/publications/Incidents/DOCS/ComAndRep/China… "The captain was not only unable to assess the situation properly, he was confused by it; therefore, he was unable to take the necessary action to correct the situation." "*The Safety Board can only conclude that the captain was distracted first by the evaluation of the engine malfunction and second by his attempts to arrest the decreasing airspeed, and that, because of these distractions, he was unable to assess properly and promptly the approaching loss of airplane control. The Safety Board also concludes that the captain over-relied on the autopilot and that this was also causal to the accident since the autopilot effectively masked the approaching onset of the loss of control of the airplane.*" (emphasis mine) Rewriting: We can conclude that VM was distracted first by the mention of the ies4lin and second by attempts to attribute the problem to ies4lin, and that, because of these distractions, he was unable to assess properly the issue at hand. One also concludes that VM over-relied on the features of the development process automation (bugzilla) and this this was also causel to tine incident since data available from bugzilla effectively masked the real problem. This is a classical pattern, so I'd be hard pressed to call Vitaliy "incompetent". Overdependence on bugzilla and some fatigue, that's what it is if you ask me. Cheers, Kuba

Aug. 2, 2007

Re: Is there a process for reviewing a bugzilla staffer?

by Kuba Ober

On Wednesday 01 August 2007, Vitaliy Margolen wrote: > Whit Blauvelt wrote: > > Hi, > > > > Is there a formal process for reviewing an arguably incompetent bugzilla > > staffer? Obviously it wouldn't be to submit their name as a bug. But is > > there any defined administrative layer that concerns itself with people > > on that level who are dragging on the project? > > > > I looked around a bit for information on this. Sorry if it's posted > > somewhere and I missed it. > > > > Thanks, > > Whit > > To spare everyone time and to skip directly to an entertainment see bug > 9147: http://bugs.winehq.org/show_bug.cgi?id=9147 I agree with Whit. Most of your writing in that bug report would be in line with lack of sleep or prolonged fatigue, or some other factor that causes you to be compartmentalized in your own verions of things and completely ignore the real issue at hand. Similar behavioral pattern that happened on China Airlines Flight 006. The resemblance is striking: the pilots completely unaware of what the real problem is, and were dealing with non-issues (rather than fluing the plane). Similar thing here: the user tells you one thing (the real issue), your situational awareness is as if something entirely different has been taking place (dupes, etc). Interesting. http://en.wikipedia.org/wiki/China_Airlines_Flight_006 http://www.rvs.uni-bielefeld.de/publications/Incidents/DOCS/ComAndRep/China… http://catless.ncl.ac.uk/Risks/3.79.html [...] the captain had become so preoccupied with the dwindling airspeed that he failed to note that the autopilot, which relied on ailerons only, not the rudder, to maintain heading, was using the maximum left control- wheel deflection available to it to overcome the thrust asymmetry due to the hung outboard engine. When the right wing nevertheless began to drop, ... the captain didn't notice the bank on the attitude indicator ... . When he did notice it, he refused to believe what he saw. At this point, ... the upset had begun and the captain and first officer were both spatially disorientated. You can almost substitute terms from the bugreport for the flying terms above... Common thing to happen when you're tired, distracted, etc. So this is nothing personal, just noticing a pretty common problem. BTDT, one has to learn to recognize the first signs and take a break (helps me). At least here it won't kill anyone. Now, if you *are* sleeping well (and long enough), and are not tired, then IANAD and wouldn't know what to do either... Cheers, Kuba

Aug. 2, 2007

Re: Patch: VarWeekdayName

by Juan Lang

> Thank you. Hope it will be better this time. Also, I'll send a test > if this is OK. This one looks pretty good to me, but I have one error and a few nits to correct: The error: + { + ERR("GetLocaleInfo of 0x%x failed in 2nd stage?!\n", localeValue); + SysFreeString(*pbstrOut); You should set *pbstrOut to NULL in this case. The nits: You have a couple small errors in the comments: - You misspell iWeekday - The comment for iWeekday in the params section implies 0 is allowed, but the first check in the function disallows it. You also inconsistently put spaces after commas - please do in all cases. Attaching a test with the patch would certainly help. --Juan

Aug. 2, 2007

RE: Is there a process for reviewing a bugzilla staffer?

by EA Durbin

I don't think we need to be rude and poke fun at new wine users by pointing out their mistakes to everyone. He may someday prove to be a valuable asset to the project, or may be driven off from contributing altogether because a dev/admin had to point out his errors for "entertainment" purposes. I don't see being rude to new users "entertainment", it comes across as being kind of a bully and deters people from contributing. We're all linux/wine newbs at some point, and telling them their posts are useless information instead of trying to help them in a friendly fashion is going to end up driving them away from the project.> Date: Wed, 1 Aug 2007 21:09:13 -0600> From: wine-devel(a)kievinfo.com> To: wine-devel(a)winehq.org> Subject: Re: Is there a process for reviewing a bugzilla staffer?> > Whit Blauvelt wrote:> > Hi,> > > > Is there a formal process for reviewing an arguably incompetent bugzilla> > staffer? Obviously it wouldn't be to submit their name as a bug. But is> > there any defined administrative layer that concerns itself with people on> > that level who are dragging on the project?> > > > I looked around a bit for information on this. Sorry if it's posted> > somewhere and I missed it.> > > > Thanks,> > Whit> > > > To spare everyone time and to skip directly to an entertainment see bug > 9147: http://bugs.winehq.org/show_bug.cgi?id=9147> > Vitaliy.> > > _________________________________________________________________ See what you’re getting into…before you go there. http://newlivehotmail.com

Aug. 2, 2007

Re: dinput - Allow the use of the standard Joystick GUID when calling CreateDevice

by Christoph Frick

On Thu, Aug 02, 2007 at 06:54:12AM -0600, Vitaliy Margolen wrote: > >OK, so how do i force my system to use the other implementation (so i > >can test it) ? > >I have a Logitech WingMan Extreme (old version). > Just (re)move /dev/input/js*. Or in dinput change device name to point to > non-existent directory/device (in joystick_linux.c). or on systems with udev and friends just dont load joydev. just evdev. then this devices will not be created (even on non-udev boxes /dev/input/js* would not work). -- cu

Aug. 2, 2007

Re: dinput - Allow the use of the standard Joystick GUID when calling CreateDevice

by Vitaliy Margolen

Peter Dons Tychsen wrote: > On Tue, 2007-07-31 at 20:05 -0600, Vitaliy Margolen wrote: >> Peter Dons Tychsen wrote: >>> On Tue, 2007-07-31 at 06:34 -0600, Vitaliy Margolen wrote: >>>> Peter Dons Tychsen wrote: >>>>> On Mon, 2007-07-30 at 21:20 +0200, Peter Dons Tychsen wrote: >>>>>> On Sun, 2007-07-29 at 17:43 -0600, Vitaliy Margolen wrote: >>>>>>> Peter Dons Tychsen wrote: >>>>>>>> OK. Please review this diff: >>>>>>>> >>>>>>>> I will re-submit it if you like it. >>>>>>>> >>>>>>>> /Pedro >>>>>>> Alright looks good now (you might want to remove the extra white space your >>>>>>> patch adds - git complains about those). Just left to make the same change >>>>>>> to the other joystick interface :) >>>>>>> >>>>>>> BTW don't forget to cc: the wine-devel list when you replying. >>>>>>> >>>>>>> Vitaliy. >>>>>> OK. I still feel that trying to sync joystick_linuxinput.c and >>>>>> joystick_linux.c is out of scope for this patch. But as my steadiness >>>>>> has limits i have done some of it anyway... :). I have kept the changes >>>>>> modest. >>>>>> >>>>>> Please take a look at the new patch. >>>>>> >>>>>> On another note i will agree with you that it would be practical if the >>>>>> two files had similar (or maybe even shared) code. Redundant code is >>>>>> never very practical as it always ends up as this very example. The two >>>>>> implementations which were supposed to identical always drift apart. If >>>>>> things are supposed to do the same, keep them together to begin with. >>>>>> >>>>>> Thanks, >>>>>> >>>>> Maybe i would be more successful if i actually attached the >>>>> patch.... :-) >>>>> >>>>> Here it is.... >>>> Just few small things left: >>>> >>>>> -#undef MAX_JOYSTICKS >>>> As I mentioned earlier you should move this instead of removing it completely. >>>> >>>> >>>>> static HRESULT joydev_create_deviceW(IDirectInputImpl *dinput, REFGUID rguid, REFIID riid, LPDIRECTINPUTDEVICEW* pdev) >>>>> { >>>>> - int i; >>>>> - >>>>> - find_joydevs(); >>>> You removed a really important function call here. >>>> >>>> >>>>> +static HRESULT joydev_create_deviceA(IDirectInputImpl *dinput, REFGUID rguid, REFIID riid, LPDIRECTINPUTDEVICEA* pdev) >>>>> +{ >>>>> + unsigned short index; >>>>> + >>>>> + if ((index = get_joystick_index(rguid)) < MAX_JOYDEV) { >>>>> + if ((riid == NULL) || >>>> If you reformat the whole function, please make it 4-space indented. >>>> >>> OK. Here is the new patch: >>> >> Looks good to me. The problem is, it doesn't work for me (USB joystick). I >> think you forgot to look at how joystick_linuxinput.c handles that data3 >> field. It's not just 0 based index... >> > I told you i should bot have merged the changes over to > joystick_linuxinput as they were too different... :-) > > OK, so how do i force my system to use the other implementation (so i > can test it) ? > > I have a Logitech WingMan Extreme (old version). > Just (re)move /dev/input/js*. Or in dinput change device name to point to non-existent directory/device (in joystick_linux.c). Vitaliy.

Aug. 2, 2007

Re: Direct3D Game test framework

by Stefan Dösinger

> To make this useful, we need to solve 'DirectX detection failed' bug, so we > can run real tests nightly. Could you send me ~/.wine directory you are > using with latest WineHq? Do you have HKCU/Software/Wine/Direct3D/DirectDrawRenderer set to "gdi" perhaps? This disables D3D support altogether. You could try with a fresh .wine, it should run 3dmark2000 and 2001 out of the box. I'm not sure wether I should really attempt to send you my ~/.wine, it is full with games and has a size of 51GB :-) . I could send you the .reg files though.

Aug. 2, 2007