How to Create a Ticket
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 development (git master branch) (report:14)
- That this is really a bug or patch, and not a feature request. Feature requests should go in the Feature wishlist Forum.
- 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, check the buildbot. If the buildbot succeeded, then the problem is with your compile environment, either toolchain or dependency issues. Seek assistance on the e-mail the users list. If the buildbot failed, then we already know of the problem and unless you are supplying a patch to correct it, we don't need a ticket. If this is for an operating system or architecture for which we do not offer continuous integration, seek confirmation on the mailing list before opening a ticket.
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 developer's 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 are not currently allowed. Due to heavy spam, tickets and comments will only be accepted by the spam filter if accompanied by a valid email address. Your full address will not be publicly visible, so there is no need to worry about it being abused.
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. Make sure to read the line where it says to attach this as a file.
- 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 (Crash), 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:
Bug Report - If you are reporting a bug but have not attached a patch.
Patch - If you have attached a patch to fix a bug.
Developer Task - 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.
