KMeleonWiki > Documentation > BugTrackingSystem

Note: the bug tracking system described on this page is no longer in use. Active development currently takes place in the forums.

The BugTrackingSystem (BTS) is used to keep track of all reported bugs in K-Meleon. All users are welcome to report bugs, but please read the short text on how to submit a helpful bug report first: Our BugReportingGuidelines.

Quite some people report their bugs at the discussion forum. (the forums are older than the BTS and mailing list, but no more used for bugs/rfe:s or development) It's a good thing to discuss the issue before reporting any bugs, but we need someone to actually file a bug report when the issue at hand really is a bug. Too much is left in the forums and flushed out and forgotten within a month.

All new bugs are set as 'Unconfirmed'. They need to be confirmed. Make a search for all unconfirmed bugs.

Not all bug reports are easy to understand. It is okay to ask the bug reporter to include some more information in that case. Maybe point him towards the bug reporting guideline mentioned above.

When you have found a bug report that makes sense try to repeat the steps described. Do you see the same misbehaviour? Write a comment! (especially if you use another kmeleon and/or windows version) If you had to make guesses or change anything in the procedure to repeat the bug you should really add those things in your comment.

Not all bugs noticed with K-Meleon are actually "K-Meleon bugs".. K-Meleon is not much more than a user interface in front of Gecko, the Mozilla rendering engine. Gecko handles the network connection and cache, parses the html/xhtml/css files and renders the pages as well as runs the javascripts (and third-party plug-ins: java, flash) and so on. If you suspect a reported bug is actually a bug in the underlying Gecko engine you can check how Mozilla's official test application for embedding Gecko on Windows behave. Download mfcEmbed (embed-win32.zip) from any Mozilla mirror. Since Mozilla 1.5, mfcEmbed is not more included (builded) in his nightly builds. This is the last mfcEmbed (embed-win32.zip) included in Mozilla archives: http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/2003/10/2003-10-07-16-1.5/embed-win32.zip

All confirmed bugs are set as 'Open' or 'Open Mozilla bug'. Make a search for all open bugs.

Usually a bug goes from Open to Fixed when a fix is committed to the CVS by a developer. Sometimes this is forgotten. Can you find some bugs that you know have been fixed? Make a comment! We want them correctly tag such that they all can be closed later.

Open bugs are acknowledged as problems that need a fix. Can you help figure out what part of K-Meleon this involves. Does turning some plugins on or off change the bahaviour? prefences? Any help in tracing down the root of the problem is a good thing.

Check the Mozilla bugs. Is there a bugzilla number? Is that bug still open? Is the bug still around in K-Meleon? in mfcEmbed? Add a link to bugzilla if it's missing, change the number if the old was closed and a new reopened, and so on.

Not all fixes are good fixes.. Search for all fixed bugs and test them with a new build of K-Meleon from CVS. Did the fix really make the bug go away? Write a comment! (one comment is enough, unless you wish to say that the bug is still around while the earlier comment say otherwise)

Usually bugs go from Fixed to Closed when a new version is released, but sometimes bugs are closed for other reasons than being fixed:

• Duplicates: We sometimes see that the same bug is reported more than once. Make a comment when you see this. Link to each bug from the other and close one of them.
• Invalid: Sometimes the bug reporter is plain wrong. Maybe the problem is just that one or another preference is not set.
• Won't fix: This is most often for a request to add more ie/opera/netscape/and-so-on like shortcut keys and menu entries by default. We cannot be like all other browsers at the same time.

Old bugs, reported for ancient kmeleon versions, can probably also be closed if no one has made a comment that the bug is still around. It is simple enough to open a new bug later anyway; and a new/recent bug reporter means a bigger chance to receive extra information asked for.

The severity of a bug is roughly used as:

• Very important -- Crashes and data losses
• High priority -- operational bugs, the browser is not working well as a browser: download, https (also internationalization issues have been judged as high priority bugs)
• Normal -- normal bugs, some part of kmeleon is not working the way it should
• Low priority -- minor bugs and things that can be worked around with macros or third parties utilities.
• Not important -- cosmetic bugs, default preferences, menu entries, accelerators. can easily be postponed until it is time for a new release

Requests for Enhancements (RFE): We use the BTS to keep track of all requested new features as well. Comments on how these new features should work are always welcome. Make a search for all RFEs.