wiki:TicketHowTo

Version 49 (modified by robertm, 14 years ago) (diff)

--

We eventually look at all tickets. But if you go through this quick checklist before submitting the ticket, it will be addressed more quickly.

Important Unless you have something valuable to add, such as a patch or further relevant debugging info, do not post a comment to an existing ticket. 'Me too' posts are strictly forbidden. Discussion about a bug or the potential fix belongs on the mailing lists and not in the ticket system, the results of the discussion may however be appended to the ticket and should be concise, dealing in facts.

First Steps

First, please verify that:

  • Your bug doesn't already have a ticket (report:6)
  • Your bug wasn't recently reported (report:17)
  • That your bug is not already fixed in current SVN (report:14)
  • That this is really a bug or patch, and not a feature request. Feature requests should go in the wiki.
  • Special for nuvexport: please read nuvexport Debug Mode to make sure that is a problem with nuvexport and not with one of the programs that it references (e.g. lacking mp3 support in ffmpeg is not a nuvexport bug).

If this is a compiling problem, e-mail the users list, then the developer list before adding a ticket. These are often caused by toolchain or dependency problems. Of course, if the problem is only present after a particular recent commit, e-mail the developer list immediately.

Opening a Ticket

It is highly recommended that you set up a valid trac session which will make any ticket you create include your name or e-mail address. To do this go to "Preferences" at the top of the page and type in your name and e-mail address, then click the "Save changes" button. This can speed up the addressing of your ticket because you may be able to respond to a developers queries while they are looking at a problem rather than responding later and waiting for them to have time to look at your ticket again.

Important - Anonymous tickets will receive less attention and may in future be banned because of recent abuse by anon users.

Once you've decided to create that ticket:

  • Select the correct component from the list. (GoToDev)
  • Set the version to the version you use. If you see the bug with multiple version, choose the newest. Add the output of mythfrontend --version or mythbackend --version to the ticket.
  • Enter a concise description of the problem along with the steps to reproduce, stick to the facts. Do NOT use hyperbole and do NOT make threats, show respect for the person who will spend their times triaging the ticket or fixing the bug, failure to follow these rules will make it likely that your ticket will go ignored.
  • Make sure you attach logs, patches, and backtraces after you create the ticket.
  • If problem causes a SEGFAULT, attach the backtrace to the ticket.
  • If you submit a patch, make sure it adheres to the MythTV coding standards.
  • Please do not increase a ticket's priority, severity, or milestone from the defaults. These fields are for the person who is fixing the issue to decide. Don't change these after the ticket's been filed, either - they'll likely just get changed back.

Use the ticket types as following:

Patch - If you have attached a patch to fix a bug.

Defect - If you are reporting a bug but have not attached a patch.

Enhancement - If you have attached a patch to add a feature or improve something.

Task - Generally reserved for developers to create a reminder about planned work and collect information in one place.

To attach a patch or a backtrace, you must first create a ticket, and then there will be an 'Attach File' button when you view the new ticket. Attach logs as either plaintext or compressed files, please do not attach non-plaintext files such as OpenOffice, Word, or RTF documents.

What Next?

Have patience, there are many tickets and developers have so little free time. Your ticket may be answered in minutes or it may take months. Your ticket is no more important than another unless a developer decides so, please respect their decisions. Demanding a response or 'bump'ing your ticket will cause annoyance and will affect how developers deal with you in the future.

Posts such as "me too" are tantamount to bumping a ticket. If you'd like to indicate that you are also affected by a bug, that a patch or workaround worked for you, or in any way discuss the ticket, you should do so on the dev mailing list.

If your ticket gets marked as "worksforme" or "invalid" consider this a challenge to improve the bug report. Problems often only occur with a particular setting, with some particular hardware or even with a specific recording. Figuring out what exactly is causing the problem will make it possible to reproduce the bug, which is the first step in fixing it. If the ticket is marked as invalid rather than worksforme, it probably failed some check on this checklist. Also, don't get into an argument with whoever closed your ticket. Remember, since this person reviewed your ticket, this is the person most likely to fix your problem.

Keep a close eye on your ticket. If you are asked to provide information (ticket marked as "infoneeded"), please do so promptly. Failure to provide the requested information within 30 days may mean that your ticket is closed.