Building A Better Bug Report
A common exchange in the previous length thread deals with the proper place to enter bug reports. Here it is:
Now that I have posted this information, I will revert to the previous policy of unceremoniously deleting bug reports that are posted as comments to any blog entries.
Let's look at those fields on the bug report form:
- Name and email-- you may not like to surrender this information but if we can't reproduce your bug report and we can't follow up with you for more information about your unique configuration, we have no choice but to dismiss your bug report.
- Product name: Please be sure to select "Flash Player" so it gets routed to the right place; not "Flash Lite Player" and certainly not plain "Flash".
- Remember to select Browser; you can safely disregard web and app server and database fields.
- The correct OS is also important to select for proper handling.
We're always particularly interested in crash bugs, especially ones that bring down the browser every time. Obviously, these don't happen with our many configurations in-house (not even with Firefox 2, which I'm currently using on my Gentoo dev box) or we would fix them before the Player got out the door.
Comments
No arguments here, Mike.
I've got to tell ya though, that Adobe bug reporting system leaves alot to be desired. Atleast from a bug reporter's point of view (I have no clue what it looks like on your end).
Something that doesn't feel quite so much like dropping pebbles down a well may make the process more inviting for bug reporters.
Cheers,
A.
Posted by: andrew | January 23, 2007 02:56 PM
While the bug report/wish form looks a little impersonal, it's the best way to let Adobe know what you think. I've spoken to Adobe employees in person, and if I have a good idea, they tell me to send it to the wish form too because it has a big impact on future features and determining the importance of bugs.
Posted by: Josh Tynjala | January 23, 2007 04:35 PM
Have you taken the 1000(?) character limit off the description box? It makes it really hard to post stack traces, or any other useful info, with that in place :-/
Posted by: Shish | January 23, 2007 08:35 PM
I use the report form the other day and found it very pro-active. Someone was in touch with me within the day.
Usability eise (the title here is 'Building A Better Bug Report') the field where you enter your comment could be bigger. Its surrounded by whitespace, but just a little TextArea in the middle. It makes it very difficult to read what you are writting. Use some of that whitespace and make it wider and higher.
Posted by: Tink | January 24, 2007 02:02 AM
A question: I've reported a few gflashplayer problems to the beta site after the final version was released (found the link in my browser history). Should I re-report them to a wish form, or may I expect those to still be reviewed?
[ Try re-reporting them, please. -Mike M. ]
Posted by: RQ | January 24, 2007 08:04 AM
Something that doesn't feel quite so much like dropping pebbles down a well may make the process more inviting for bug reporters
Posted by: 三洋伺服 | January 24, 2007 09:01 AM
Even though that form might work very well, I'd prefer to see the current list of issues (ie mozilla's bugzilla). I dont like to submit issues that might already be known.
So, any chance we'll get a link to 'known issues'?
[ "WMODE." That accounts for about 97% of the current known issues. -Mike M. ]
Posted by: ArmEagle | January 24, 2007 11:32 AM
Speaking about bugs, there is an issue about [........] should I submit a bug report?
[ Yes. -Mike M. ]
Posted by: Kostas | January 24, 2007 05:00 PM
Hmm, Mike M. Maybe it is because it's late here.. But I totally didn't get your comment.. :P
If it's just me, just leave it like that.. but well..
(ie no need to post this as comment)
Posted by: ArmEagle | January 24, 2007 06:07 PM
sometimes I do bug report especially if the bug keeps coming back...
Posted by: Trisha Parks | January 24, 2007 11:51 PM
Speaking of the infamous WMODE issue: is this something that needs to be fixed in the plugin? The browser? Both? Neither?
[ A bit of both. -Mike M. ]
Posted by: Carnildo | January 25, 2007 11:03 AM
pcm.compress { type ladspa slave.pcm "plughw:0,0"; path "/usr/lib/ladspa"; plugins [ { label dysonCompress output { controls [ 0.0 0.1 1.0 1.0 ] } } ] } pcm.pcompress { type plug slave.pcm "compress"; }Above is my ~/.asoundrc.
I'm trying to normalize volume of flash9.
How do I make flash9 to use pcm.compress?
I see some files in ~/.macromedia/Flash_Player/macromedia.com/support/flashplayer/sys.
Is there a way to edit those force flash9 to use pcm.compress?
For now, I changed pcm.compress to pcm.!default. So, the volume of flash9 is normalized. But i want only flash9, not other applications, to use that slave.
Posted by: Glen | January 25, 2007 09:30 PM
I might have missed this in other online documentation - but where is the mms.cfg file that the Flash 9 Security whitepaper mentions, to be found on a Linux system? Or does Linux have other means of system-wide configuration of the Flash Player?
Posted by: csant | January 28, 2007 02:30 AM
Hi, I submitted a bug report about a week ago, including my e-mail address and all. But I did not even get a receipt confirmation, or a bug number, or anything. How can I track the status of my bug report?
Posted by: DavidB | February 1, 2007 09:57 AM