find-maint: Bugs

1 
1 9 Bugs
1 ******
1 
1 Bugs are logged in the Savannah bug tracker
1 <http://savannah.gnu.org/bugs/?group=findutils>.  The tracker offers
1 several fields but their use is largely obvious.  The life-cycle of a
1 bug is like this:
1 
1 Open
1      Someone, usually a maintainer, a distribution maintainer or a user,
1      creates a bug by filling in the form.  They fill in field values as
1      they see fit.  This will generate an email to
1      <bug-findutils@gnu.org>.
1 
1 Triage
1      The bug hangs around with 'Status=None' until someone begins to
1      work on it.  At that point they set the "Assigned To" field and
1      will sometimes set the status to 'In Progress', especially if the
1      bug will take a while to fix.
1 
1 Non-bugs
1      Quite a lot of reports are not actually bugs; for these the usual
1      procedure is to explain why the problem is not a bug, set the
1      status to 'Invalid' and close the bug.  Make sure you set the
1      'Assigned to' field to yourself before closing the bug.
1 
1 Fixing
1      When you commit a bug fix into git (or in the case of a contributed
1      patch, commit the change), mark the bug as 'Fixed'.  Make sure you
1      include a new test case where this is relevant.  If you can figure
1      out which releases are affected, please also set the 'Release'
1      field to the earliest release which is affected by the bug.
1      Indicate which source branch the fix is included in (for example,
1      4.2.x or 4.3.x).  Don't close the bug yet.
1 
1 Release
1      When a release is made which includes the bug fix, make sure the
1      bug is listed in the NEWS file.  Once the release is made, fill in
1      the 'Fixed Release' field and close the bug.
1