Jump to navigation Jump to search


1,375 bytes added, 07:52, 26 November 2012
→‎How to triage bug reports: Final draft of Bug Triage Guidelines.
* Any new bug should be assessed for the following:
** Is the bug title line formatted correctly and sufficiently descriptive?
*** Currently, we use the same kind of prefix at the start of the title as we do in commit messages. See [[Commit_Guidelines#Rules here]] for description of these. The prefix should indicate the sub-team who should do further investigation i.e. the engine name for engine specific bugs, the backend name for platform specific bugs etc. If unsure, then initially the bug should be assigned to the relevant engine team, rather than the platform team.
*** You should try to ensure that the game short name (and platform, if relevant) are included in the title.
*** These rules are to help developers who browse or search the bug list to locate bugs relevant to their engine or platform by visual or text search.
*** If changing the title from the user's original value, please ensure to transfer any information removed to a comment, if not otherwise present.
** If the bug is missing any of the following required information, then a comment should be added to ask the user to confirm thisprovide the missing information:
*** Name of game (preferably with language/variant).
*** Exact version of Operating System/Platform i.e. Windows XP SP1, rather than just Windows.
as this: or other tool from [[Reporting_unknown_MD5_checksums]] would be
A developer with the same game should then generate the same type of file listing with md5sums and compare the file attached by the user to see if it indicates that this is the problem.
** If the bug report comments "this used to work" or other indications of a regression, then a comment should be posted asking the user to perform a "gross" bisection:
Can you please test this with previous versions of ScummVM i.e. <list reasonable range/versions of ScummVM
releases to test, starting with previous version (N-1)> and confirm when this problem was introduced? This will
greatly reduce the amount of work involved in locating the cause of this bug.
Once the user has confirmed a "bad" and "good" revision, a developer should then try to locate the exact regressive commit using Git bisection and post a followup comment with the id of the regressive commit and the short commit message.
** If a developer some further investigation on a bug, then any lessons, partial conclusions, short useful text debug traces, savegames etc. should be added to the bug tracker item as attachments or comments. This is partly as a medium for discussion of possible solutions, but mainly on more complex or troublesome bugs to checkpoint any progress.


Navigation menu