Guideline for creating issues » History » Version 6
Andreas Smas, 01/20/2012 11:46 PM
1 | 1 | Andreas Smas | h1. Guideline/Rules for creating issues |
---|---|---|---|
2 | 1 | Andreas Smas | |
3 | 6 | Andreas Smas | * Don't reuse bugs. If a bug has been closed and it's not the *exact same* issue, file a new bug. |
4 | 6 | Andreas Smas | |
5 | 3 | Andreas Smas | * Don't create duplicate bugs. At least try to skim the list before posting a new one. |
6 | 3 | Andreas Smas | |
7 | 2 | Andreas Smas | * For bugs: Always write the version where the bug is found. There is a specific field for that. This does not apply for features. |
8 | 1 | Andreas Smas | |
9 | 1 | Andreas Smas | * Don't write multiple bugs/feature requests, etc in one single ticket. It's harder to discuss and know when things are done. |
10 | 1 | Andreas Smas | |
11 | 4 | Andreas Smas | * Unless you know that the bug is a regression (ie, something that worked fine in a previous version of Showtime), please try using the latest version of Showtime before filing the bug. The official versions are found "here:https://github.com/andoma/showtime/downloads. If you are using your own builds or builds from somewhere else you better be sure what you are doing. |
12 | 4 | Andreas Smas | |
13 | 1 | Andreas Smas | * If a file is unplayable for whatever reason you must attach a sample of it or it is almost impossible for me to figure out what's wrong. |
14 | 1 | Andreas Smas | |
15 | 5 | Andreas Smas | * If the sample file is bigger than > 500 MB (it usually is for movies) the file can just be cut into pieces. 50Mb should be enough. This does not work for all fileformats but for AVI and MKV it should work fine. |
16 | 1 | Andreas Smas | ** On Windows use this tool: http://www.filesplitter.org/ |
17 | 1 | Andreas Smas | ** On Linux use the *dd* command: @dd if=<originalfile> of=cut.mkv bs=1000000 [email protected] to generate a 50MB file |
18 | 5 | Andreas Smas | |
19 | 5 | Andreas Smas | * If you are worried about attaching sensitive material to a ticket, make the ticket private (available when the ticket is created). By doing so only a small set of trusted developers (currently two people) will be able to access the contents. |
20 | 1 | Andreas Smas | |
21 | 1 | Andreas Smas | Failure to comply with these (simple) rules will result in the issue being rejected. If you thing that's unfair for me to impose these rules consider the amount of time I've spend on the project so far. Badly written tickets will just consume more of my time that I could spend on new features instead. |
22 | 1 | Andreas Smas | |
23 | 1 | Andreas Smas | Thank you for understanding, |
24 | 1 | Andreas Smas | Andreas |