<?sphp $this->text('pagetitle') ?>
 
Home of the Squeezebox™ & Transporter® network music players.

Bug Process

From SqueezeboxWiki

Revision as of 19:34, 8 April 2012 by Soulkeeper (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Contents

Before you file a bug

Before you file a new bug, please do the following:

1. Consider whether your issue is really a support problem. If you are the only person who has noticed a terrible problem with a release that has been available a while, chances are it's something specific to you. Visit http://www.logitechsqueezebox.com/su...t-support.html for official product support. Search messages here in the forums or post a new message to see if other people have seen the same symptoms.

2. Try the latest stable nightly build of Squeezebox Server and see if the bug is still there. http://wiki.slimdevices.com/index.php/Nightly_Builds

3. Search existing bugs that are open OR resolved to see if your issue has already been noticed. If you find your bug, update it with additional information you think may be important. https://bugs.slimdevices.com/query.cgi

Filing a new bug

When you file a bug, you want the bug to be fixed as quickly as possible so you can improve your enjoyment of your Squeezebox. So what makes a good bug? From our standpoint, the goal of any new bug should be to make it easy for our developers to understand the problem and make the required changes to fix the bug.

Towards that goal, a LIST OF STEPS TO REPRODUCE the bug are the biggest help. These allow any QA engineer, developer, or even manager to experience and understand the bug. You may be asked to create and attach "log files" created by the server software's internal logging function. These are a running commentary by the software as it runs, and can often provide insight into the cause of the problem.

Screen shots and videos are sometimes useful, but we prefer words. Bugs are also turned into test cases for future software versions, and it's difficult to do this with videos. Also, we periodically run complex queries of the bug database to look for trends in reported bugs. Screen shots and videos make it harder to search for bugs using Bugzilla's text search feature.

Attaching music files, playlists, or .prefs files can also be useful if a specific file seems to be causing the problem.

When you are done entering the detailed description of the bug, READ BACK OVER IT and try to verify if it really has all the information another person would need to reproduce and understand what you're reporting.

There are also a number of other data fields to fill out:

  • Summary: A short summary of the bug. Should be more specific than 'No sound' but shorter than the full description.
  • Product, Component, Platform/OS: Lets us know a few more details that might be important to reproducing the bug.
  • URL: A link to a useful URL, most often a link to a conversation here on the forums about the bug.
  • Target, Assigned to, Priority, Severity: Logitech people or special bugzilla users will set these fields later.
  • Description/comments: These fields are where all the other information goes. Some information that is often useful includes the software Version or build number (for player firmware)

To go ahead and file a bug, go to https://bugs.slimdevices.com/enter_b...&format=guided

Bug flow

At any time someone might edit your bug to make it more correct. If you disagree with the change, post a comment about why!

After you create a new bug it has a life cycle peculiar to the Squeezebox team. At first, it will have a status of "unconfirmed." This means that that only a very small number of users are seeing this bug. If a bug has a certain number of votes, it will become "confirmed". Employees and some community members also have the ability to confirm bugs. If your bug doesn't have enough information to reproduce or understand, you will be asked for more details before your bug is confirmed. If you feel like your bug is particularly important, feel free to visit our forums and encourage people to vote for it or confirm it.

After a bug has been confirmed, it is moved to "new" status. Usually, it will be assigned to "Unassigned." These bugs are reviewed by Logitech QA people and given priorities, targets, and assigned to a developer. If its not immediately clear what these fields should be, this process can take up to a week or so.

After that point, the bug is the responsibility of the assignee. If a particular developer doesn't have time to work on it, it may be assigned to someone else, or it might be retargeted for a future version.

What you can do to help

Anyone:

  • Confirm bugs: Search our Bugzilla system for unconfirmed bugs (https://bugs.slimdevices.com/buglist...us=UNCONFIRMED). See if you can reproduce the bug on your system! If there's not enough info, or you can't reproduce the bug, post a comment to the bug asking for more information, or describe what steps you followed to try to reproduce.
  • Vote for bugs: If you can reproduce the bug or if you're already being annoyed by the bug, vote for it! Voting for bugs will automatically confirm them, and is used by our QA team and developers to prioritize bugs.
  • Add additional information in comments: If have noticed any more detail about the bug, add it! If the original post was about MacOS but you also see the bug on windows, add it! If the original bug was about all music files, but you only see the bug on MP3 files, add it!
  • Link forum conversations in URL: if there's a forum thread about this bug, make sure the URL of the thread is in the URL field!

Power users:

  • Check if critical information is there: If you are familiar with our products, you can easily tell if a bug has enough information to reproduce. Ask for any missing information we need!
  • Attach sample files which display the bug: If you can isolate a file which can help reproduce the bug, attach it!

Community Developers:

  • Fix things! If you see a bug with a lot of votes, or that you are interested in that is not yet assigned to a developer (many of these will be targeted for "Future"), feel free to post to the bug noting you're working on a patch. Even if the bug is assigned to a developer, post a question about whether you could take over the bug. Participate in our developer forum at http://forums.slimdevices.com/forumdisplay.php?f=5. Attach patches for review and inclusion in the software!

What if something in Bugzilla is broken/ignored/wrong?

If you see a bug that isn't being treated properly, or anything else wrong with the bugzilla system, our bug flow, or software engineering practices, you can:

  • Post to the forums http://forums.slimdevices.com to see if other users know something about it!
  • Send me email at chris_owens@logitech.com. Note that if you need technical support on one of our products, I'm not very good at helping people with common problems, and might totally ignore you. Our tech support team is much better at that kind of thing. You can contact them at http://www.logitechsqueezebox.com/su...t-support.html

Thanks for helping improve our products!

You may also want to read the Bugzilla User's Guide to find out more about Bugzilla and how to use it.