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.

Alternative Perspective

Here is how one might expect a typical bug to pass through the system.

  • Bug is reported on the mailing list
  • Developer copies this over to Bugzilla, creating a NEW bug.
  • Developer is reviewing the bug list, and sees a bug they wish to claim. They change its status to ASSIGNED, and assign themself as the owner.
  • Work continues apace.
  • The developer has a proposed patch, which is assigned to its own Git "topic branch" on their repository.

    The developer attaches a link to this patch, or perhaps a copy of the patch, to the bug, and marks it RESOLVED+FIXED

  • Some verification takes place. Ideally, another developer confirms that the fix does what it ought to. Perhaps additional changes go into the patch.
  • Consensus is arrived at that the patch is good to go into one or more branches of Slony-I.
    • The patch is applied to those branches, and committed.
    • Notes about the bug are added to the release notes, and committed.
    • They add indication to the bug of application of the changes, so readers know what version(s) of Slony-I may be expected to have this fix.
    • The bug is marked CLOSED.