Reporting Bugs
Siete pregati di segnalare i bug che trovate presso il Launchpad Bug Tracker di Inkscape. Opzionalmente, potete anche iscrivervi alla lista degli sviluppatori di Inkscape per discutere il problema direttamente.
Your bug reports are vital for making Inkscape a robust and capable application. It is an important goal that each Inkscape release be stable, crash-free, and behave itself well. Bug reports from users are the primary means of quality assurance, as we rely on the Open Source principle of "Many Eyes Make Bugs Shallow".
If the bug you report to the bug tracker is not fixed promptly, this may mean developers cannot reproduce it, or cannot understand your description, or are simply too busy with other things. Be persistent. As the original reporter, you are the person most interested in fixing it, so if your first report had no effect, you must not let it drop. There are many things you can do to help push your bug closer to a fix:
- Segnalate il bug al tracker. Non aspettate che lo faccia qualcun altro. È importante, altrimenti la vostra segnalazione potrebbe venire dimenticata rapidamente. (Ma prima controllate il tracker, il vostro bug potrebbe già esser stato segnalato.)
- Allegate tutte le informazioni: versione, piattaforma, lingua, operazioni per riprodurlo, e file di esempio e screeshot se utili.
-
Se si tratta di un crash, è importante allegare un backtrace. Per ottenere il backtrace,
usate gdb in questo modo:
gdb <percorso dell'eseguibile di inkscape executable> (gdb) run [parametri (opzionali)] # Ripete le operazioni che portano al crash del programma (gdb) bt
e mandateci l'output. Tutte queste operazioni posso essere fatte anche su Windows, il binario di gdb per Windows è disponibile presso http://www.mingw.org/download.shtml. - If you really want the bug to be fixed, try to find out the exact
point in time when the bug appeared. At the very least, test old
Inkscape versions. To get a narrower and more useful estimate, use
backdated CVS checkouts (the -D switch) to find the most recent date
on which the CVS was is OK, and also the first date on which it is
broken. Then we can make a diff between these two dates to figure out
the reason. If you manage to find the day of breakage and if that
day's diff is big (which is possible, given the rate of checkins
we're having on average), try to narrow it down to a few hours. For
example:
cvs -d:ext:your_sf_login@cvs.sf.net:/cvsroot/inkscape checkout -D"2004-04-04 12:00" inkscape
will give you the CVS as it was on that date at midday. I think this should work with anonymous CVS access too.
Windows users can do the time search easily by downloading builds from "Development/Compiled Packages/Win32 Builds" link on the download page and finding the first one that doesn't break.
