Is there a process for reviewing a bugzilla staffer?

[Whit Blauvelt]

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

[James Hawkins]

On 8/1/07, Whit Blauvelt <whit(a)transpect.com> 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.

This is an open community.  If you have a problem with someone or some
process, let it be known.  There is no formal process except for
communication on wine-devel.

-- 
James Hawkins

[Vitaliy Margolen]

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.

[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/ChinaA...

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

[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/ChinaA...

"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

[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

[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

[Kuba Ober]

On Thursday 02 August 2007, Chris Morgan wrote:
> > 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?

IMHO, you succumb just the same to completely ignoring the real problem at 
hand. Mind you, flt 006 flight crew was not one person only, yet they were 
all equally confused (or so it seemed, at least PF and FE were).

Nowhere did the bug reporter indicate that he used ies4lin on the failing 
configuration.

"Coincidentally, ies4lin, which runs fine
on prior versions of Wine, doesn't accept URL line input in 0.9.42."

The user just mentioned this as a coincidence. He then explicitly states:

"InfoSelect is broken on a fresh installation before ies4lin is installed to 
it"

Then, VM rambles once more and finally says that he's sorry for missing an 
attachment.

I admit there's a chance that previous installs were not done correctly by WB, 
just like the #4 engine *did* get hung in flt 006. The deal is that in both 
cases, the engineer who should have worked the problem did something to 
exacerbate the issue. VM didn't, IMHO, follow the best approach to get WB to 
check if he reports the results from a correct install (this is not really 
documented AFAICS). In 006, the FE didn't follow the correct procedure to 
un-hang the engine (close bleed air valve).


So, now the bug is on the right track. If what Mikolaj Zalewski suggests to 
check turns out to be the culprit, this will be, in the end, an easy one. 
Just like flt 006 was an easy one once the pilots went below the clouds and 
saw what the airplane was really doing. Either way, most of VMs doing was 
consistent with being generally confused and not letting the bug-reported 
reality sink in. Again, this is not an indication of incompetence -- well 
trained people (IIRC human factors) will tend to do it more than untrained 
ones, given right combination of external factors (fatigue, etc). Heck, being 
in a grumpy mood can make you act like this -- as long as it's transient, 
it's something that one can expect to see and can live with :)

Cheers, Kuba

[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/ChinaA...
>
> 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

[Alex Waite]

Chris Morgan wrote:
> 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/ChinaA...
> >
> > 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.

As a Gentoo user, I would have to agree.   If a fairly good document is 
put together a lot of headaches can be avoided.  When they are done 
following the guide then bugzilla staff and others can help them.  The 
advantages of this are twofold.  One is that there are fewer headaches 
from chasing down weird compile time options, etc.  The second is that 
Gentoo is a more advance/complicated distro and some of the users really 
know their stuff and can be quite useful.  By providing good 
documentation we might encourage those users to participate more.  Weed 
out the bad, keep the good.
> Chris

---Alex

[Kuba Ober]

> > > > > 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/Ch
> > > inaAir/AAR8603.html
> > >
> > > 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...
> > 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.
> As a Gentoo user, I would have to agree.   If a fairly good document is
> put together a lot of headaches can be avoided.  When they are done
> following the guide then bugzilla staff and others can help them.  The
> advantages of this are twofold.  One is that there are fewer headaches
> from chasing down weird compile time options, etc.  The second is that
> Gentoo is a more advance/complicated distro and some of the users really
> know their stuff and can be quite useful.  By providing good
> documentation we might encourage those users to participate more.  Weed
> out the bad, keep the good.

Umm, how exactly does Gentoo affect the "legacy" compilation of an 
autotools-based tarball, where you simply untar, configure and make install 
which normally will go to /usr/local/...? I'd expect this to work the same on 
my FC6 system, just like it used to work on a FreeBSD system last time I 
checked (a few months ago).

If wine is not overzealous by design in finding its bits and pieces (I doubt, 
since I don't recall seeing such a bug) and gets correctly invoked, AFAIK it 
will ignore any existing installations and do its thing.

I'd routinely have version A of wine installed from an rpm, and one or more 
local versions installed in $HOME for testing before deployment. Somehow it 
had just worked. Heck, every once in a while when I need two or more versions 
of wine deployed at the same time from an rpm, that'll work just fine too (a 
development tool or two used to require an older wine version to work).

As a more useful measure, I'd suggest bug reporters who run into possible 
compilation issues to post their ~/.bash_history with the set of lines 
starting at untarring the package up to running the test. Should enable easy 
finger-pointing and take minimum time. In such a case, VM could have 
said "see line 45 of your history, you've done foo which will not work due to 
xyz, ask on #wine-users for a correct way of doing it". If there's a better 
way of providing "steps to reproduce the problem" with a bug report (in this 
case), I'm all ears.

Cheers, Kuba