ubuntu-defect-analysts team mailing list archive
Mailing list archive
Re: The latest and greatest in reporting ...
On 10/19/2011 08:10 AM, Brad Figg wrote:
On 10/19/2011 08:00 AM, Kate Stewart wrote:
On Wed, 2011-10-19 at 07:21 -0700, Brad Figg wrote:
I have created some of the reports for the QA team, the
release manager and the hardware enablement team. I've
pulled all of this scripting together into a single, small
git clone git://kernel.ubuntu.com/bradf/ubuntu-bug-report-kit
Some of the latest improvements:
1. I've fixed up the two css themes that I use so the
"light" theme looks just as good (if not better)
than the "dark" theme. I actually prefer the light
theme myself now.
Very much like the "light" them as well. :)
2. I'm particularly happy with a new filtering tab that
I've added to the reports. This allows the user to
easily filter out parts of the report that they are
not interested in. For an example, look at:
Really like the concept here!! a lot!!! :D
Given the filtering available on releases, probably need to clarify that
the release specified is "release when the bug was found". I started
selecting/deselecting and had to ponder for a sec, when I selected
"Precise" and there was nothing there. ;) Possibly adding the letter
of the release to the Found column? ie. beta-1 would become
"O beta-1" or even "O B1"; when we get to the milestone releases, this
would remove ambiguity about how old the bug is.
As I was sending this out I noticed that the "Found" and "Target" relate
to Oneiric and not Precise so I've updated the section that looks at the
date found and use Precise dates instead of Oneiric. Maybe this needs more
I like the "Oneiric beta-1" / "O beta-1" idea, will look at what that
will take to implement.
I've implemented this. I'm not exactly loving how it looks but it does
differentiate the milestones.
A couple of other bits of feedback from when I started clicking around,
a) can no longer click on the bug number to hotlink to the bug itself.
This was really useful, can it please be put back. :)
*Facepalm!* Yup, that's a bug.
b) Reports currently aren't showing the closed stats of the bugs
Now that this can be explicitly filtered in the options tab,
probably be good to pull them into the report?
Your report, your call but putting all bugs that are also close and marked
as rls-mgr-p-tracking could get noisy. The filtering is a "nice to have"
but not required. Adding all that will make it required for most folks
looking at the report.
Now, this code still doesn't match up with certain coding
standards and probably works differently that some people
would like but it's doing what I want it to and if you can
make use of any of it or any of the ideas, you are welcome
to do so.
Fully intend to. Thank you again. :)
Brad Figg brad.figg@xxxxxxxxxxxxx http://www.canonical.com