Reporting Bugs

From Plogger Codex

Jump to: navigation, search

Plogger is relatively new, and like all other software, it has bugs. As developers, we can not test every possible situation and we rely on the community to discover and report bugs so that we can fix them and make good software. For tracking, we request that all bugs and feature requests be reported the same way so that, at the end of the day, we have some semblance of what is going on. Continue reading to learn how to report bugs and help the Plogger project.


Contents

Reporting security issues

Security issues do happen. We ask that if you believe you've found a security issue in Plogger that you please email security at plogger dot org with the relevant information and we'll address the issue as soon as possible.

It is standard practice to notify the vendor (the Plogger developers, in this case) of a security problem before publicizing so a fix can be prepared and public damage due to the vulnerability minimized.


Reporting Bugs in Plugins and Themes

Because most plugins and themes for Plogger are external to the project, we can not be responsible for fixing bugs in them. Please DO NOT follow the instructions on this page.

For plugins and themes that are not part of Plogger, please check the documentation included with the plugin or theme for instructions. If there was no documentation included with the plugin or theme, you'll need to contact the author directly.


Overview of Bug Reporting and Resolution

The lifecycle of a bug involves several steps from discovery to resolution. Here's an brief overview; more information can be found below.

  1. A user finds a bug in Plogger.
  2. The user tries to replicate the bug and verify that it is actually a bug.
  3. Once it is determined to be a bug, the user submits a bug report (called a ticket) in [Trac].
  4. A Plogger developer (or user) confirms that the bug exists and that it should be fixed. They mark the ticket accepted so that it can be addressed.
  5. A Plogger developer (or user) decides to fix the bug. They may choose to take responsibility for the bug by clicking on the start option on the bottom of the ticket. This lets others know that a fix is being worked on so time is not wasted on duplicate work. The developer figures out how to fix the bug and creates one or more patch files and uploads them to Trac. They then click the test action at the bottom of the ticket to indicate that a resolution exists and needs to be tested.
  6. Members of the Plogger developer group (including volunteers) test the patch to see if it fixes the bug and doesn't break anything else. They add notes to the ticket to indicate their results. If feedback shows the patch is unsuccessful, the fail action will be set so that more work can be done. If the patch works as expected, the pass action will be set so that it can be committed.
  7. One of the developers with authority to modify the official Plogger source code commits the patch to the code in the SVN repository.
  8. Finally, the person that commits the patch sets the ticket status to closed and the resolution to fixed. See Bug Resolutions below.


Details of Bug Reporting and Resolution

This section is an expanded explaination of the steps outlined above.


Before You Report a Bug

Because of the large size of the Plogger community, there is a good chance a bug you found has already been reported. Because of this, it's very important that you check to make sure it's not already in the system before you report it. If you've never reported a bug before, it might be a good idea to discuss it with a more experienced developer before reporting it.

  1. Search for your bug or feature request in Trac by using a Search or Query.
    • If your issue has already been reported, please do not report a duplicate bug. If you have more information to contribute, please log in and add a note to the existing bug.
    • If your issue is similar, but not quite the same, you can add a note to the existing one or report a new one. Sometimes it can be hard to decide if your issue is similar enough or not. In general, if you have more information to contribute, please add a note to the existing ticket. If you believe it is different enough or it is a recurrance of a previously closed issue, please report a new ticket.
    • If your issue was recently reported then closed, and you do not agree with the resolution, you can also reopen the ticket and leave a comment as to your reasoning.
  2. If you would like to discuss a bug before reporting it you can post a question to the Plogger Support Forum, discuss your issue on the #plogger IRC Channel, or on the Developer Mailing List.


Reporting a Bug

  1. Read Before You Report a Bug (above), and verify that you have a new bug to report.
  2. Read this article on How to Report Bugs Effectively and the Trac Ticket documentation.
  3. Log into Plogger Trac using your support forum username and password. If you don't have a forum account register, so that you can log in to Trac. This is essential for communication about your bug, since the developers may need more information (and you can not create a ticket without logging in).
  4. Click New Ticket in Trac to reach the bug reporting page.
  5. Fill in the following fields on the new ticket page:
    Short Summary
    Make the summary short but informative and accurate, as this is the ticket title that will be displayed in search results.
    Full Description
    Fill in a full description of your bug or feature request. Include a description of the problem, steps someone else would have to take to reproduce the problem, maybe an example of the bug in action (i.e. a URL), and a description of why it is a problem worthy of being corrected. Also include information about your platform, such as operating system, web server software, PHP version, MySQL version, and Plogger version. The better your description, the better the chances of having the bug resolved promptly.
    Ticket Properties
    Priority
    You will need to decide on a priority for the issue -- this is how urgent the bug is. Unless it is a critical bug, this is best left to the default as developers will usually rank the bug's priority.
    Component
    Select the component of Plogger where the bug was found
    Severity 
    The significance of the issue. Select a severity based on how critical you consider the issue to be. If in doubt, leave this option as Normal.
    Assign to
    If you know of the developer who is responsible for the code that the bug is in, place their Trac username here. You can also take responsibility for the bug yourself, by putting your own Trac user name here. This is optional and could speed up developer attention to the bug.
    Milestone
    By what version this issue should be resolved, at the latest. Do not change this. This is an option that Plogger developers will set.
    Version
    The version of Plogger where the bug was found. You can find the version number of Plogger in the header of the admin panel.
    Keywords
    Keywords that will make it easier for developers to find the bug, and identify the areas it affects. An example might be 'import' for a bug involving the import mechanism in Plogger.
    CC
    Who bug information and updates should be sent to. If you want to be kept informed, enter your own Trac user name here. You will then be notified by email any time a change is made to this report, or a note to the bug is added. Don't ignore these emails; any time a change is made, be sure to check the report for updates. Developers may need further information from you, and this is their only way of getting in contact with you. Note: you need to go to the Trac Settings page to set your email address. Putting it into your Support Forum profile will not get it into Trac for purposes of CC messages.
  6. Click Submit Ticket (after previewing it). Then pat yourself on the back.


Finding Bugs to Fix

If you're ready to help make Plogger better and are familiar with PHP, this is one of the best ways to help out. Here's a few steps on tracking down bugs to fix.


Patching Bugs

If you're familiar with PHP and MySQL and would like to help fix bugs in Plogger, we encourage you to create and submit a patch so that it can be tested and applied to the main Plogger code. Here are a few steps to get you started.

  • Read Finding Bugs to Fix (above), and find a bug to fix in Trac.
  • Connect to the Plogger Subversion (SVN) Repository and download the latest code. If you aren't familiar with Subversion, please read Using Subversion. All patches should be submitted against the latest code in the SVN repository.
  • Figure out how to fix the bug by modifying the Plogger core files. You may want to discuss your proposed solution on the plog-dev mailing list before finalizing it.
  • Test your fix to verify that the bug has been fixed and that nothing else in Plogger was broken in the process.
  • Create a patch file or files containing your fix. This is basically a diff of the fixed file(s) and the originals from SVN. If using TortoiseSVN, you can read Creating and Applying Patches on their site.
  • Upload the ticket using the Trac Attach File button and add set the action to test.


Bug Resolutions

A ticket in Trac starts its life in the open status, and (hopefully) is eventually closed. When a ticket is closed, it is marked with one of the following status designations:

  • If your bug has been reported elsewhere, it will likely be closed with duplicate.
  • If the bug has already been fixed in the latest subversion code (which is probably not what you're running unless you have a local test blog), then it will be closed with fixed.
  • If it is decided that your bug isn't in fact a bug, but is the intended behaviour, it will be closed with invalid.
  • If no-one else can replicate the symptoms you describe, it will be closed with worksforme.
  • If your bug is a feature request that the developers don't want in the core, it will be marked as wontfix.

Please verify that your bug doesn't fall into one of these categories before submission.


Notes

  • The processing of your bug may require your participation. Please be willing and prepared to aid the developers in resolving the issue.
  • Don't be upset if your bug gets resolved as "Not a bug" or "Won't fix". What seems like a bug to you may very well be a "feature". These resolutions just mean "not going to fix now", maybe in the future it will be a priority to solve.
  • Thank you for contributing to the development of Plogger!
Retrieved from "http://codex.plogger.org/Reporting_Bugs"
Personal tools