 |
 |
|
|
| Project Admin Area |
slony1 Home | Slony-I Website | Git Info | Mailing Lists | |
|
|
|
Slony-I Bug Processing
Slony bug tracking is being managed using Bugzilla.
Here is the Slony-I Bugzilla Instance .
Bug Management Process
Bug
Lifecycle Documentation uses the following image 
to characterize the flow of work on bugs, through various states, as
they (hopefully!) get fixed.
The following interpretations are suggested.
NEW
When a bug is created, it is created with NEW state, is assigned to slony1-bugs@lists.slony.info, and an email is sent to the bug tracking list.
At this point, someone on the Slony development team should examine the bug to ascertain what, if anything, should be done with it.
It may be appropriate to:
- Assign it to someone that is expected to work on it, changing the owner, and change the status to ASSIGNED.
- Perhaps the bug is trivially resolved, in which case, it is reasonable to jump straight to marking it RESOLVED.
- Perhaps the bug is invalid. Jump straight to RESOLVED.
- Perhaps it is unclear who should work on it. Perhaps the bug should be left alone, or perhaps it should be ASSIGNED to someone who might know who should do the work.
ASSIGNED
This is the state of bugs that belong to someone. That someone should presumably be a human, and not slony1-bugs@lists.slony.info.
RESOLVED
This is the state of bugs that have been addressed, after some fashion.
There are several possible resolutions:
- FIXED - believed to be resolved
- DUPLICATE - this apparently duplicates some previous bug
- WONTFIX - a problem that we don't plan to address
- WORKSFORME - the developer can't duplicate the issue
- INVALID - the problem is considered part of the proper behaviour of Slony
Note that this is not the end of the lifecycle!
If a developer has a patch for a complex issue, it is appropriate to:
- Attach a patch, or perhaps a reference to a Git commit for the proposed fix.
- Mark the bug RESOLVED/FIXED
- Reassign the bug, either to:
- The person that reported the bug
- The slony1-bugs@lists.slony.info user
- A specific Slony developer that is to validate the fix as VERIFIED
VERIFIED
A developer (or user) takes a RESOLVED bug, and evaluates whether the resolution provided is proper.
The same resolution values apply:
- FIXED - believed to be resolved
- DUPLICATE - this apparently duplicates some previous bug
- WONTFIX - a problem that we don't plan to address
- WORKSFORME - the developer can't duplicate the issue
- INVALID - the problem is considered part of the proper behaviour of Slony
At this point, for complex patches, we can consider that the patch has been verified to be valid to be committed and released.
The bug might be re-assigned back to the original developer to do the commit. But wait, it's not CLOSED yet...
CLOSED
The final destination for a Slony bug is for it to be closed. The fix should have passed through phases of being ASSIGNED RESOLVED VERIFIED. For particularly simple bugs, or for issues considered to not really be bugs, these phases may be rather brief.
A bug being marked CLOSED should indicate that we have put it into some specific release, and placed a suitable reference into the release notes.
REOPENED
Oh, no, the zombie bug!
Sometimes bugs aren't solved in the first attempt, and need to be reopened. This is pretty much equivalent to ASSIGNED.