The Linux-HA project has a public bugzilla at http://developerbugs.linux-foundation.org/ (thanks to OSDL for hosting it for us) to complement this Wiki. This page tries to give some hints at how to best use the bugzilla, and how the interaction between the Wiki and the Bugzilla might work out in practice.

Bugzilla guidelines

Bug tracking

The obvious useage for bugzilla is of course to track bugs in released versions of heartbeat. Every bug should be entered there; a user reporting a bug can either do this himself after registering, or post the bug to the mailing lists (if the user doesn't feel to comfortable with adding it himself), and then a developer should filter it into bugzilla for tracking and resolution.

Information to provide in bug reports

• Always try to reproduce the bug with the latest version of the release series you are running first. If running 1.0, please consider upgrading to 1.2. In particular if you are running the development 1.99.x version, try the latest!

• Always include the exact version numbers of heartbeat and the resources you want to run, the operating system environment (distribution, kernel version).
• Describe the hardware environment (storage, networking, STONITH power switches) you are using.

• Describe exactly the steps needed to reproduce the behaviour, and what behaviour you would expect instead.

• Attach the relevant configuration files from both nodes - ha.cf, haresources, authkeys at least - and the excerpts from the logfiles from starting heartbeat to the bug you are reporting.

• There is a good explanation of various approaches to bug reporting at http://www.grassouille.org/blogmax/041009.html.

Note to self: Maybe we should provide a heartbeat-bug-reporter tool which gathered the data automatically to make sure nothing gets lost.

Development tracking

We also use the Bugzilla for tracking not-yet-implemented features. The bugzilla is very helpful in documenting who is currently working on it, and who passed the ball on et cetera.

• The version number should reflect the version number by when we expect the feature to be completed. See HeartbeatRoadmap for an outline of the version numbers and their dates.

• Use the severity with common sense: A blocker means the given version number can't possibly released before this is completed, and thus should be used sparingly.

  Experience shows that bugzilla is bad for long-winded feature discussions; here the Bugzilla entry should refer to a longer and complex discussion of the feature and it's design in this Wiki, and the discussion should probably take place on the mailing lists.

• If a release is done and the feature was not implemented in time, it should be moved forward to the new target release.

Bugzilla states

Bugs should be in NEW as long as nobody is yet working on them, ie while we try to figure out who should take it. As soon as the right person takes it over and actively starts working on it, it should move to ASSIGNED.

Linux-HA site built by the Linux-HA crowd. HTML4 / CSS2