Bug Report Life Cycle

This page describes the life of a bug report.

  • When a bug is first reported, it is given the NEW status.
  • Once a developer has started, or is planning to work on a bug, the status ASSIGNED is set. The "Assigned to" field should mention a specific developer.
  • If an initial patch for a bug has been put into the Gerrit code review tool, the status POST should be set manually. The status POST should only be used when all patches for a specific bug have been posted for review.
  • After a review of the patch, and passing any automated regression tests, the patch will get merged by one of the maintainers. When the patch has been merged into the git repository, a comment is added to the bug. Only when all needed patches have been merged, the assigned engineer will need to change the status to MODIFIED.
  • Once a package is available with fix for the bug, the status should be moved to ON_QA.
    • The Fixed in version field should get the name/release of the package that contains the fix. Packages for multiple distributions will mostly get available within a few days after the make dist tarball was created.
    • This tells the bug reporter that a package is available with fix for the bug and that they should test the package.
    • The release maintainer need to do this change to bug status, scripts are available (ask ndevos).
  • The status VERIFIED is set if a QA tester or the reporter confirmed the fix after fix is merged and new build with the fix resolves the issue.
  • In case the version does not fix the reported bug, the status should be moved back to ASSIGNED with a clear note on what exactly failed.
  • When a report has been solved it is given CLOSED status. This can mean:
    • CLOSED/NEXTRELEASE when backport of the code change that fixes the reported mainline problem has been merged.
    • CLOSED/CURRENTRELEASE when the code change that fixes the reported bug has been merged in the corresponding release-branch and a version is released with the fix.
    • CLOSED/WONTFIX when the reported problem or suggestion is valid, but any fix of the reported problem or implementation of the suggestion would be barred from approval by the project's Developers/Maintainers (or product managers, if existing).
    • CLOSED/WORKSFORME when the problem can not be reproduced, when missing information has not been provided, or when an acceptable workaround exists to achieve a similar outcome as requested.
    • CLOSED/CANTFIX when the problem is not a bug, or when it is a change that is outside the power of GlusterFS development. For example, bugs proposing changes to third-party software can not be fixed in the GlusterFS project itself.
    • CLOSED/DUPLICATE when the problem has been reported before, no matter if the previous report has been already resolved or not.

If a bug report was marked as CLOSED or VERIFIED and it turns out that this was incorrect, the bug can be changed to the status ASSIGNED or NEW.