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

[Aaron Bennett]

This is very interesting.  I hope someone is writing a quick "how-to: 
participate in the Red Hat development process" or something similar, 
with instructions for using bugzilla, the URL to red hat's bugzilla 
server, who to contact for logins, policies on cvs access, as well as 
red-hat specific triage procedures, etc.


Michael K. Johnson wrote:

>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
>http://developer.gnome.org/projects/bugsquad/triage/
>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.
>
>Thanks!
>
>michaelkjohnson
>
> "He that composes himself is wiser than he that composes a book."
> Linux Application Development                     -- Ben Franklin
> http://people.redhat.com/johnsonm/lad/
>
>
>--
>Rhl-devel-list mailing list
>Rhl-devel-list at redhat.com
>http://www.redhat.com/mailman/listinfo/rhl-devel-list
>  
>


-- 
Aaron Bennett
UNIX Administrator
Franklin W. Olin College of Engineering