As an aside,
including a replication procedure in each bug report really,
really helps a developer pick it up to start repairing
it. I know Darrell does a good job of this, but perhaps other members of
the team could do some triage and append a bug replication process to bug
reports that do not currently contain one?
How about just looking through every bug report and making
sure they are organized, still valid, and are actual issues?
I mean i know it's dull and there are hundreds of bugs, but
there's always a few that linger that have been solved or
need status changes. I feel bad telling anyone to sit there
for hours and look over each page, manually testing each
problem, but it might be well worth it.
No need for exhaustive energy and time. Use the advanced search features. Here is what I
see:
Blockers: 20
Critical: 31
Major: 74
Normal: 159
Minor: 72
Trivial: 18
Enhancement: 113
Wish list: 7
Granted, one person's "Blocker" is another person's "Works for
me." Regardless, if a person takes the time to file a bug report, regardless of
perceived category, then let's not waste time arguing category. Just fix the bugger.
No need to get fancy or get overwhlemed. Let's start with the Blockers.
As I mentioned in a previous post, there are patterns to many of these bug reports. For
example, teach me how to resolve one of the "Sym Links Incorrect" reports and
likely I can resolve the others. Teach me how to resolve one of the "unknown icon
type" reports and likely I can handle the others.
This is the case for many of the bug reports. People like David and me need only an
example or two and we are sufficiently motivated thereafter to resolve similar issues and
propose a patch for related bugs.
That's what this list should do: help one another so we all learn. As we each learn we
reduce the load against any one person. As we each learn we more quickly resolve future
related bugs because more people know the solution. The faster we work as a team, the
happier the users.
Note: I am updating all reports I filed that are related to building and added "Build
issue:" as a description prefix, even if the package builds with work-arounds. I will
browse the entire bug list and append obvious reports with the same prefix and provide an
update to this list later.
Darrell
