On 29-Sep-07, at 11:01 PM, erland wrote:
>
> Some examples:
> 1. What information am I as a bug reporter responsible to provide:
> -- Severity ? (Or is this something the SqueezeCenter QA team will set
> ? )
You can set it, but be reasonable. Certainly clear what the
difference is between enhancement and all others. Try not to use
critical or blocker when it isn't.
> -- Priority ? (Should I enter the priority from my point of view,
> or is
> this someone else likes to do ?)
In my experience, it's not used. however, where to spend time and
effort should be up to the developers or qa who are responsible for
what is to be done and when.
> -- Target milestone ? (Should I enter when I think it should be fixed,
> or is this something someone else likes to do ? )
leave this undefined. qa reviews and decides which should be part of
a given release. jumping the gun just gets the way of trying to
focus efforts for each release.
an exception might be if you are planning to create a fix yourself in
time for a certain release.
> -- URL ? (What should this point to ?)
anything you have as a reference. If there is a forum thread or
website related to the issue, feel free to add something there.
> -- Component ? (Should I do my best guess, or will the developers set
> this correctly anyway ?)
>
Best guess. qa or dev's will reset if there is a better place for
it. Sometimes it changes once a more likely cause is determined. The
symptoms don't always make it obvious and components do overlap.
It's not critical, but it helps for searching to have it as close as
possible.
> 2. When a patch is provided in a bug report am I as the person who
> initially wrote the bug report responsible to verify the patch (if I
> can) ?
if you can. otherwise there are several hard-working folks as SD who
can try. If you have a proposed patch, sometimes the reporters are
able to test and verify that it works for their case too.
Verification really helps when it comes to deciding to merge someonee
else's patch without being able to verify it yourself.
>
> 3. After I have verified a patch, am I responsible to change some
> state
> on the bug report or is it enough to just post a comment in the bug
> report that I have verified the patch ?
comment is about all you can do, really. Sometimes having a simple
patch or workaround can lower the severity (in cases where "simple
workaround" being available makes a difference). if you end up with
commit access, then you comment on the change number of the commit
and mark as fixed, with the next release as target (qa/support will
verify /close). In cases where reporters are asked to verify, they
may be asked to mark it fixed (which reporters can do) or to reopen
if there are issues.
>
> 4. When a correction has been comitted to svn, am I as the person who
> initially wrote the bug report responsible to verify the correction
> (if
> I can), or is this something the SqueezeCenter QA team will do
> anyway ?
>
Usually the developers who commit the fixes have done some
verification. QA does as well, but the more the merrier. As a
reporter you do have the ability to mark the bug as REOPENED if you
try it at some point and find a problem. sometimes the setups can
cause different issues to arise.
> 5. After I have verified bugreport where a correction has been
> comitted
> to svn, am I responsible to change some state on the bug report ?
>
i think reporters are able to verify, but you don't HAVE to. it's
always nice to have the feedback that it has worked. Until a bug is
CLOSED, the comment box is always available. Assignees, reporters
and anyone on the CC list get copied on the comments and state
changes. If you see other bugs via searches, feel free to add
comments or add your email to the CC list if you want to be notified
about the responses.
> 6. If I provide a patch on a bug report, should I change some state on
> the bug report or is it enough to just provide the patch to get
> someone
> to notice that there is a possible working solution available ?
>
If you provide a patch, please add your email to the CC field so that
you can be notified of any questions or updates. Sometimes it can be
a long time. I've got patches that go back years on there, but the
requested clearance/responses haven't been given.
>
> The most important issues I'm personally a bit worried about:
> - I don't want to close bug reports which I think is corrected if this
> means that they will be missed when the SqueezeCenter QA team does
> their tests or write the release information about corrected bugs in
> the release.
If you are the reporter, and it's fixed for you then it's right to
mark as FIXED. They don't disappear, but they do get lowered in
priority on the QA review lists.
If you aren't the reporter, you can't close anyway but you can
comment that you think it IS fixed. that always helps because there
are so many that do get fixed either by someone who is not aware of
the bug report or as collateral effects from another change. Some
issues just become moot due to feature/design changes. I found an
easy bug to fix tonight, that I had simply missed in all the activity
of bug updates ("recent" filter didn't help, but that happens
sometimes, like when it's review day)
> - I don't want to spend time testing things that the SqueezeCenter QA
> team is going to test anyway. There are of course cases where
> duplicate
> testing is a good thing, but there are also cases where it would be
> enough if at least one person tested it.
it's never a waste of time. I've been doing it for a few years now,
and even with a QA team involved, there is always room for more folks
on board. If you are the slightest bit hesitant, comments are always
good. Leaving the status unchanged is fine. Other people do get
around to it. Try to be patient, even when it feels like you are alone.
> - I don't want a correction on a bug I've written to be untested, just
> because I thought someone else would test it.
Please make sure that you make note that any correction is untested,
as it is assumed that any proposed change of state or patch does come
from some sort of testing.
Much of the above is based on my opinions. It is how I conduct myself
on bugszilla, and generally what I will indicate in comments
(especially if reporters assign a target at time of reporting) .
Hopefully Chris will chime in if I'm incorrect on any point.
-kdf
_______________________________________________
beta mailing list
[email protected]
http://lists.slimdevices.com/lists/listinfo/beta
