Goats... [was: Include OpenOffice.org 1.1 in Severn?]

Michael K. Johnson johnsonm at redhat.com
Mon Aug 18 18:41:00 UTC 2003

I suppose this is going off in the direction of being a development-related
discussion, so rhl-devel-list is probably the best place to discuss it.

On Fri, Aug 15, 2003 at 03:27:57PM -0600, Jared Smith wrote:
> Actually, I was just wondering... What parts of Red Hat Linux require
> the most work to get ready for a new version?  Is there anything mere
> mortals like myself can do to help out the situation, with a little
> effort, in our spare time?

Hmm.  One of the things that fits the "spare time" model better than
trying to contribute to packaging is probably bugzilla triage.  In
particular, looking for dups, bugs filed against the wrong component,
and bugs that need more info would be quite helpful.

When you have a set of duplicate bugs, the first thing to do is
to find not the earliest report of the bug, but the clearest one
with the most information.  This is often not the earliest report;
if it were, chances are better it would have been resolved already.
Then mark the other bugs as duplicates of the best report, with
like "this bug might be a duplicate of bug #nnnnn".  If you use
that exact form, "bug #" followed by the bug number, bugzilla will
helpfully convert the text into a hyperlink.  :-)

When you are looking for bugs filed against the wrong component,
there are two possibilities: bugs that filed against 4suite (the
first component in the list) and bugs that are more subtly wrong.
Common "subtle wrongness" includes bugs filed against mount, pppd,
acpid, etc. that are really kernel bugs (and vice versa), and bugs
filed against applications that are really in libraries used by
the applications.

Bugs that need more info are often "foo breaks" without much
more information.  If you see a vague bug report that you know
how to get more information on, you can chime in and politely
suggest some ways to get more information.  If you can actually
reproduce the bug, providing more information, especially on
how to reproduce it, is wonderful.

If you are a developer, you can even write candidate patches.
When you have one, please feel free to bring it to rhl-devel-list
for discussion if the bug owner doesn't respond within a few
business days.

The GNOME triage guidelines are at
and aren't bad reading, though our process is a bit different.
We should probably write up our own triage guidelines; I guess
this email (and perhaps a thread it might spawn) could be the
start of that.



 "He that composes himself is wiser than he that composes a book."
 Linux Application Development                     -- Ben Franklin

More information about the devel mailing list