GNOME.org
 

Re: [orca-list] Reporting bugs - what to consider and do?

Hi, Gena,
I forgot to mention one thing that I do. After I file a bug, I post a link to it on the Orca mailing list so that anyone who is interested can comment and/or keep updated on the bug. 

Take care,

dave


Georgina Joyce wrote:

Hi David

Many thanks for this well written explaination.

Oh well, that'll have upset the evolution devels.<smiles>

Thanks.

On Sat, 2008-05-31 at 16:27 -0600, David E. Price wrote:


Hi, Gena,

I'm certainly no expert on this, but I'll tell you what I do. I'm assuming
the potential bug is one of access.

- If I think I have a bug, I make sure that it is repeatable and that I know
the steps to cause the bug to appear.

-Then, I post it to the Orca list and ask if anyone else is seeing the
problem. If I get a confirmation back, I know that it is not just a problem
of my machine/configuration/etc, so I'll file the bug. If I don't get a
confirmation back, I'll often make clean, rebuild Orca, and see if I can
repeat it. (Obviously, this step doesn't apply if you aren't using Orca
svn.) If so, then I think about filing a bug.  With things that are changed
on a regular basis, like Orca svn trunk or the nightly builds of Firefox and
Thunderbird, I'll see if it persists over a few days of updates.

-Once I've decided that I have a bug, I then try to decide if it is an Orca
bug or an application bug.  This is a difficult call, because it is often
difficult to tell if it is the application that is responsible for the lack
of access or Orca doesn't have the scripts to provide the access.  If I'm
uncertain, I tend to file the bug with the Orca team, since they will be
able to determine the cause of the problem and contact the correct
development group, if needed.

-Once I've decided where to file the bug, I then search the application's
bug list to see if it has already been filed. For instance, the Orca bug
list can be found here:

http://bugzilla.gnome.org/buglist.cgi?columnlist=target_milestone%20priority%20bug_severity%20assigned_to%20short_desc&query_format=advanced&product=orca&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&order=bugs.target_milestone,bugs.priority%2Cbugs.bug_severity%2Cbugs.target_milestone%2Cbugs.bug_id

However, Bugzilla also has a search feature that allows you to search for
keywords in the existing bug reports.  Do the best job you can, but that is
no guarantee that you will find the existing bug.  I've tried different sets
of keywords for some bugs, and they weren't correct and never found the
existing bug--the bug I filed was later redirected to the existing bug.  The
important thing is that you make an attempt to find an existing bug.

-Once you believe that there is no existing bug, you can file a new bug.
Bugzilla has an easy process to follow to file a new bug. All of the fields
you need to fill in are well-defined/described. The only thing I would
suggest is, that when you are filing an Orca bug, the short description
contains the name of the application.  When you are filing a bug with an
application, you should include the word "accessibility" in the short
description of the bug.

  -All correspondence related to fixing the bug will be carried out through
Bugzilla, with email messages sent to you whenever someone else "comments"
on the bug form. That email message will provide you with a link to the
correct page in Bugzilla, so you can quickly go to the page, make comments,
answer questions, download patches, etc.

As far as using a built-in bug reporting system, I think that is fine if it
works for you. I don't believe that they are expecting you to do the
research to determine if the bug is existing, so it falls to someone to
classify the bug and determine if it is existing--this may take a little
extra time over filing the bug yourself (extra time for the bug report to
reach the correct person, that is).

If you have any questions about any of this, please let me know.  I hope
this helps,

dave

----- Original Message -----
From: "Georgina Joyce"<gena mga demon co uk>
To:<orca-list gnome org>
Sent: Saturday, May 31, 2008 2:33 PM
Subject: [orca-list] Reporting bugs - what to consider and do?




Hi All

After a recent upgrade my copy of evolution on this ubuntu hardy system
went very quiet when I press F9 to send and receive mail.

So once a sighted person informed me of what was happening.  I thought
well I'll have to raise a bug report.  So I set up an account on gnome's
site for reporting bugs.  I looked on the orca site for guidence upon
bug reporting but couldn't find anything.  If I missed it could someone
provide the direct URL?

So I preceeded on the gnome site.  Having decided to report against
evolution rather than orca.  When the site asked for the version of
evolution and gnome.  I Switched to evolution and pulled the help menu
down.  I realised that there was a menu item for reporting a bug.  So I
cancelled the site reporting and attempted to report from the help menu.
Only to find that this dialog isn't very accessible.

Anyway after a couple of attempts I managed to report the fact that the
requesting dialog for the user's keyring password is inaccessible for
orca users.  I'm left with a number of questions regarding bug
reporting.

How do you decide what application to report against when it is
concerning orca interacting with another application?

Is this bug buddy the common way of reporting bugs within gnome
applications?

Is there a simpler way of bug reporting?

Thanks.
--
Gena

http://www.ready2golinux.com

M0EBP

_______________________________________________
Orca-list mailing list
Orca-list gnome org
http://mail.gnome.org/mailman/listinfo/orca-list
Visit http://live.gnome.org/Orca for more information on Orca
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]