trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: April 2012

Re: [trinity-devel] Re: kpowersave now working without HAL

From: Darrell Anderson <humanreadable@...>
Date: Mon, 16 Apr 2012 14:00:52 -0700 (PDT)
> > 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