On Wed, 2010-07-07 at 11:04 -0400, Jonathan Kamens wrote:
> On 7/7/2010 10:44 AM, Christopher A. Williams wrote:
> > Not true. Just because YOU can't reproduce it doesn't mean it isn't
> > happening. Others have reproduced the problem and also commented as such
> > on the bug report.
> Whether or not other commenters on the bug have reproduced the problem
> is mostly irrelevant.
Not true. It shows that others are having the the exact same problem in
exactly the same way.
> What is relevant is whether or not bug triagers and/or the maintainer
> of nspluginwrapper have been able to reproduce it.
...Which the bug shows they haven't because they didn't even try.
> If they haven't, then the bare fact that other people can is useless
> to them. With the volume of bugs that come into the system, it is
> unreasonable to expect triagers and/or package maintainers to spend
> time playing around trying to find the conditions that reproduce a bug
> when they've been given little or no information whatsoever about said
> conditions from the people reporting it.
The conditions that were known at the time were reported. Further, no
additional information was requested by any triager or maintainer.
> The most common reason why a bug doesn't go anywhere in bugzilla is
> because the triagers and package maintainer can't reproduce it. This
> is not a condemnation or criticism; it is just plain fact.
> > ...but I suppose that if you had bothered to go actually read the bug
> > report, you would have known that.
> I did "go actually read the bug report." There's no reason to be
> snarky. There is nothing in the report that provides the triagers and
> package maintainer with enough information for them to be able to
> figure out how to reproduce the issue, if they are unable to reproduce
> it out-of-the-box.
Again, that's not true. And even if it were true, no additional
information was requested. In fact, the bug was never even assigned to
anyone. No action was taken at all. It was basically ignored with no
feedback.
> > So, please list out your system configuration as relevant to this area
> > of function. Perhaps you have somehow stumbled into a workable
> > work-around configuration.
> I have nothing out of the ordinary on my system. I'm running x86_64
> F13 with updates and updates-testing enabled, and I have followed
> exactly the instructions on the Wiki for wrapping the 32-bit Flash
> plugin with nspluginwrapper.
>
> If you want people to fix a bug that is affecting you but they can't
> reproduce, then it is incumbent upon you, not them, to do the work to
> figure out what's different about your system. TANSTAAFL.
OK - Now who is being snarky... Again - no further information was
requested. No action was taken at all. I don't expect triagers and
maintainers to be clairvoyant, but I do expect them to request
additional information if they feel it is needed. That's only fair.
> Note that this bug does not show up on the most frequently reported
> bugs list, which one would expect it to do if it were a widespread
> problem, given how prevalent Flash is on the Web nowadays.
> Furthermore, I scanned all the nspluginwrapper bugs going back almost
> a year and a half and did not find any other reports of this issue.
Now this part IS irrelevant. We don't triage bugs and decide whether to
take action on them based on their being popular.
That said, in your own snarkiness ("I followed the Wiki..."), you
provided what appears to be part of the solution for using the new
32-bit plugin. It still doesn't fix the issue with the 64-bit plugin.
Too bad you didn't provide that info on the BZ. The entirety of your
comment there was, "I cannot reproduce this issue." Talk about not
providing information...
Also note that the Wiki addresses installing the 32-bit plugin only. I
would also note that the wiki was recently updated - after the bug was
reported.
If you go back and re-read the bug report, you will also note that the
original problem was reported with the 64-bit version of the plugin -
not the 32-bit version. That's what was available at the time, as well
as what was the preferred plugin to use on 64-bit systems. The Wiki
doesn't refer to requirements for installing the 64-bit plugin, and
never has from what I have seen. The problem is that nspluginwrapper
also likes to wrap 64-bit plugins - and there still DOES appear to be a
REPRODUCEABLE problem if you were to use the 64-bit version of
nspluginwrapper with its corresponding 64-bit packages.
There was a missing package in the mix on my system if you want to use
the new 32-bit plugin: alsa-plugins-pulseaudio.i686 which also pulled in
9 additional 32-bit packages. I did have the 64-bit version of this
package installed.
So thanks for at least providing enough info to fix things on my system
using the 32-bit plugin (even if it was by accident). I updated the bug
report with that info so that others on the cc list can see it.
The issue with nspluginwrapper and the 64-bit plugin remains, however.
But since Adobe has pulled the 64-bit plugin for now, we'll have to wait
and see if the new version still has the problem. Based on the behavior
I'm seeing, this actually might be an issue with the 64-bit version of
alsa-plugins-pulseaudio, or that you might still need both the 32-bit
and 64-bit versions of nspluginwrapper AND alsa-plugins-pulseaudio,
which is not documented anywhere. Thus, I'd be willing to bet that going
back to pure 64-bit for everything will still re-produce the problem.
Any triagers / maintainers want to take me up on that...?
--
===================================
"The problem with socialism is that
you eventually run out of other people's money."
-- Margaret Thatcher
--
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
