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