Hacking:How To Report Valentina Bugs

From Seamly
This page contains changes which are not marked for translation.
Other languages:
  • English


How To Report Seamly2D Bugs[edit | edit source]

If you find a bug or think you find a bug, it is very important to report it. If the developers don’t know it is broken (or might be broken), they can’t fix it. So there you are at your computer trying to do something with Seamly2D and it freaks out at you. It can be a frightening experience at times.

What is Issue Tracker?[edit | edit source]

Before we begin we highly recommend you to read first section about an Issue Tracker.

First, Next, Third[edit | edit source]

First: Get out a piece of paper or open a text file and scribble down everything you can remember about what you were doing when it happened. Also write down the exact wording of any error messages you received.

Next: Go away and yell and scream and do whatever you need to do to relax again. Your next step will be to brave [1]. It is used to track bug reports and requests for enhancements (see also why we are using issue tracker).

Third: Check to see if your bug has been reported yet. Go to the Current Bug List to see if something that looks like your bug has been reported yet. Don’t worry if it has, you can still help. See the section: #Enhancing Bug Reports. If you can’t find something that sounds like your bug there, you will need to report it.

Getting Ready to Report and Reporting a Bug[edit | edit source]

The goal of the following is to give the developers as much information about what goes wrong as possible. This helps them find out what needs to be fixed.

The Steps[edit | edit source]

  1. Use seamly2D --version or the about dialog to check your Seamly2D version. Next check with http://valentina-project.org/ to see what the most recent Seamly2D release is. If your Seamly2D is old, update then try to to reproduce the bug. Your bug may have been fixed in the most recent release. If you are running Seamly2D from Mercurial, update and recompile it.
  2. Attempt to reproduce the problem. Go do what you were doing when it happened and see if you can do it again.
    If using Seamly2D for GNU/Linux, start the program from a terminal with the command seamly2D. Sometimes the program will output error messages that can help. This is especially important if Seamly2D crashes completely without warning. After reproducing the bug, copy the error messages from your terminal into somewhere where you can save them for the bug report. It is better to give too much information than not enough.
    To narrow down the exact cause of the problem, attempt to reproduce it in other ways. Prepare yourself to explain how to reproduce it in your bug report. If you are running Seamly2D in another language, try switching your Seamly2D to English so you can report menu items exactly with the English menu item name. It helps - developers generally understand English. If you cannot reproduce the bug, assume it was some weird freak event then don’t report it. If it recurs, consult with the Seamly2D Forum. Perhaps someone else can find the key to reproducing it.
  3. Prepare to face the horror. Go to the Seamly2D github repo issue tracker. If you don’t have a login yet, follow the directions to create one. The reason to do this and report a bug with your e-mail address is so the developers can contact you if they have any questions. That way if we miss some useful tidbit of debugging information, they can tell you what to do to get it. Log in.
  4. Select “Create issue”. This opens the actual entry form.
  5. Here you have to tell the developers everything about your system, your version of Seamly2D, and your bug. Just do your best to tell them about it. A crappy bug report is better than no report at all, but if you write down everything you can clearly, you will create a decent bug report.
    1. For “Title”, write a brief description of your bug. This title will help other users see if their bug might be like your bug. Write something that would help you if you were looking for a bug like yours.
    2. “Description” is the hard part. It is the actual bug report. First provide the detailed description of your bug: a brief overview of when it happened and exactly what went wrong (including error messages). Next, describe step-by-step how to reproduce the bug. Use the exact name of menu items. Describe tools, windows, and clicks as precisely as possible. If they can’t reproduce the bug, it will be very hard for them to fix it. Last, tell them anything else you can think of that might be relevant. This could include recently installed programs or hardware that might interfere with Seamly2D. Don't forget to add information about the version of Seamly2D in which you found the bug. It is the information you got with seamly2D --version. Sometimes it is very important to know which operating system you use. Bugs on Microsoft Windows, GNU/Linux GIMP or OS X are not always identical. It would be annoying to try to use a GNU/Linux for reproducing a OS X-specific bug. It is also useful to list the desktop or window manager you are using. Sometimes a problem is caused by an interaction between the two. It won’t always be relevant, but it is good to get into the habit of listing it anyway.
    3. Leave “Assignee” blank.
    4. Classify the “Kind” of your report. If you found a bug you should select "bug". You "enhancement" if you know how to make Seamly2D better. "Proposal" for reports where you can't be sure that it is really useful or not, but you still want to propose this. Use "task" if a report related to web site, documentation or any other infrastructure.
    5. Classify the “Priority” of your bug. If the bug causes Seamly2D to crash totally or do other really ucky things so you can’t use the program at all, classify it as critical. If it completely disables some part of Seamly2D, classify it as major (for example, keeps you from using a tool). Most bugs are “minor”. If you don’t know what priority to use, call it “minor”. Trivial bugs are annoying but don’t really keep you from using the program. Same priority have things like spelling errors or UI (User Interface, “the look and feel”) issues. Don’t worry if you choose the wrong priority. The people getting your bug report will adjust it. Don’t mark it higher than it really is just to get their attention.
    6. Select the appropriate “component”. If you don’t know what component it is, submit the bug under General. Descriptions of the components are available.
    7. Leave “Milestone” blank.
    8. Leave “Version” blank.
    9. Use "Attachments" if you have files or screenshots that could help in fixing a bug.

Enhancing Bug Reports[edit | edit source]

If someone has already reported a bug like yours, read the bug report carefully. Read through all the additional comments. Make sure every bit of information you know about the bug is in there. If your version is different or you had a slightly different experience with the bug, add a comment providing your information. Check the status of the bug carefully. If it is marked “WONTFIX”, see if you can provide the information needed. Do not add a “me too” comment unless your comment provides additional information that might be helpful for the developer.

If you have provided a bug report and later get more information (like a more specific error message or fancy stuff like a trace), add a comment to your original bug with that information. It is especially important to add a comment if you somehow resolve your bug. For example, you update something else on your system and the bug no longer appears. In that case, add a comment describing what you updated from what version to what version that resolved the bug.

The Wait Patiently Part[edit | edit source]

Whee!! You survived! If you managed to get through all this and submit your bug report, be happy. Be proud. You will later get e-mails about your bug. It might include a request for more information. If you get something that says your bug is not a bug, do not be discouraged from reporting in the future. Next time it might be. Submitting careful bug reports and providing additional information where possible helps make Seamly2D better. The day will come where you submit a bug and later get an e-mail that says your bug is “FIXED” or “RESOLVED”. Then you will know that some developer out there found your bug, reproduced it, and fixed it.