Re: Bugs

>>>>> "TH" == Tom Hughes <[email protected]> writes:
TH> The only reason I havn't added any comments is because there isn't
TH> a means to do so. I wouldn't normally dream of closing a bug
TH> without comments.

:)

>> (Richard, how about a web interface for adding comments?)

TH> Might it also be an idea if the originator of a bug got an email
TH> whenever a bug is changed? Plus the 'owner' of the bug if we ever
TH> have such a concept.

This should still be optional.  For example, for these 'dead' bugs,
the originator has probably forgotten about them, and don't
necessarily want to get an email out of the blue saying "fixed in
perl-current" or somesuch.

I guess we also need a policy on deleting bugs.  I think my proposal
would be "never" (unless $spam);

What follows is version .000000000000001 of the perlbugmonger
FAQ. patches welcome.

-R

=head1 NAME

perlbugmonger - the perl bugmonger FAQ

=head1 DESCRIPTION

Frequently asked questions for the perlbugmongers.

=head1 Who are the perl bugmongers?

The perl bugmongers are the Perl Bug Adminstrators.  Some of these people are
active Perl Porters, others are just interested in learning or helping out.  

=head1 What do the bugmongers do?

=over 2

=item * Clean up old bugs

=item * Organize/categorize and assign new bugs

=item * Discuss better ways for dealing with perl bugs

=back 

=head1 What is the lifecycle of a perl bug?

=over 2

=item 1. A Bug report is submitted with perlbug (to [email protected])

=item 2. A tracking number is automatically generated by the perlbugtron, and
the message is forwarded to p5p.

=item 3. A discusion (hopefully) ensues on p5p regarding a solution for the
bug.  (During this time the bug should be categorized, and possibly assigned.)

=item 4. One or more solutions are proposed, and one is approved by
consensus and/or the pumpking.

=item 5. The bug is marked as closed.

=back

=head1 How do I close a bug?

This process varies depending on the age of the bug.  There are many bugs in
the bug database dating back several years.  Many of these bugs have already
been solved in recent version of perl.  These are old bugs.  

Everything else is a new bug.

(Another way to make this distinction is this:  Anything that requires the
attention of p5p is a new bug.)

=head2 How do I close an "old" bug?

=over 2

=item 1. Perform the necessary tests to prove it has been solved.

=item 2.  Make an entry in the bug database noting the reason you are
closing it.  This can be as simple as "fixed in perl 5.6.0 (tested on
Jul 17 2000)".

The easiest way to make this entry is to send a message to
close_<bugid>@bugs.perl.org, where the content of the message is the
log entry.

=back

=head2 How do I close an "new" bug?

If there has been a thread on p5p culminating in a patch (or some other
final looking statement), mark the bug as closed.  You may wish to add
a comment along the lines of "resolved in <msgid>"

=head1 When do I delete a bug?

The short answer is B<NEVER>.

There may be times when a bug should not be in the database, for example,
spam that may have gotten through, or an exact duplicate of another
bug report.  (And in the duplicate case, it's probably better to link
the bug to the other copy, to make sure the threads keep properly.)

=head1 What versions of perl should I check for bugs to have been fixed in?

This depends greatly on when the bug was created.  Generally, you should check
5.00503, 5.6.0, perl-current, and perl-5.6.x-current.  (Theoretically, once it
works in an earlier version, it will work in all future versions, but it can't
help to perform the regression test by hand.)

=head1 AUTHOR

Robert Spier