Reporting Bug Guidelines (Русский)

Введение

Открытие (и закрытие) отчёта об ошибке в Системе Отслеживания Ошибок Arch один из возможных путей помощи сообществу. Однако, если отчёт сделан неправильно, это может оказаться более вредным - когда очень много неверных отчётов об ошибках, сообщество и разработчики теряют время, задавая вопросы и закрывая неверные отчёты.

Этот документ является руководством для тех кто хочет помочь сообществу эффективными отчётами или отловом ошибок.

До того как написать отчёт

Исследования, проделанные до того как написать отчёт, являются наиболее полезной частью работы. Но многие лишь отправляют отчёт об ошибке, не проводя никаких исследований.

Тем не менее, подготовка хорошего отчёта об ошибке, не слишком сложная задача и может быть сделана любым (новичком или разработчиком). Следующие шаги помогут вам в подготовке вашего отчёта об ошибке или запроса новой функции. Они должны быть выполнены в указанном порядке.

Глоссарий

• Upstream : Upstream (Апстримом) обычно называют сообщество, которое разрабатывает пакеты программного обеспечения для Arch Linux. Это команда, которая отвечает за создание, публикацию и документирование программного обеспечения. В Arch Linux термин upstream может использоваться для всех проектов, характерных для Arch Linux : pacman, AUR, initscripts, и т.д. ...

Просмотр дублированных сообщений

Если Вы встретили проблему или хотите предложить новую функциональность, высока вероятность, что кто-то другой уже имеет эту проблему или идею. Этот человек уже мог отправить такой запрос. В этом случае много делать не нужно и смотрите раздел Как помочь.

Список мест для поиска дубликатов:

• Arch's forum: в большинстве случаев, здесь вы найдете свою ошибку и ее решение.

• Arch's Система отслеживания ошибок: It sounds obvious, but the "Reject as duplicate" feature in a bug tracker would not exist if people looked for duplicates before reporting bugs ... Some bugs may have already been reported to the software developers, and even some bugs may have been already fixed recently. That is why it is important to look for recently closed bugs as well as new bugs.

• Google or your favorite search engine: Search using your software name, version and a relevant part of the error message that you got, if any.

• Upstream Forum, Mailing List and Bug Tracker: Look directly at the source of your problem! Some bugs may have already been reported to the software developers, and even some bugs may have been already fixed in the development version. That is why it is important to look for closed bugs as well as new bugs in upstream 's bug tracker.

• Other distro forums: The Free Software community is wide, and people other than archers may have a good idea too! You might have a look at Gentoo's forums, Fedora forums and Ubuntu forums. If you know some other sources of useful information feel free to add them here.

Баг или Фича (Особенность)?

Если еще никто не отправил отчёт об ошибке в Arch или Upstream, Вы должны спросить себя является ли Ваша проблема Багом или Фичей :

• Багом является то, что должно работать, но не работает, так как это предусматривалось разработчиком.
• Фича (Особенность) это означает то, что программa делает или будет делать, если кто-то разработал это.

Проблема в программе или в дистрибутиве?

Это очень важный вопрос. Проблему, не имеющую отношения к Arclinux, не решить, посылая багрепорт в Arch.

Посылая сообщение об ошибке на уровень выше(то есть разработчикам), вы не только поможете пользователям и разработчикам, но и другим людям сообщества.

Как только вы это сделали или узнали другую важную информацию от разработчиков, может быть полезно разместить её на багтрекере Arch, так что о ней будут знать как разработчики, так и пользователи Arch.

Итак, за что же отвечает Arch?

• Свои проэкты: Pacman, AUR, Initscripts, сайты Arch. Если вы не уверены чей это проект, посмотрите в информации о пакете (pacman -Qi package или через вебсайт) URL разработчика.

• Создание пакета. Как правило, создание пакета заключается в том, чтобы достать у разработчиков исходный код и собрать его с нужными параметрами, следя чтобы пакет был правильно установлен в системе и работала основная функциональность программы. Создание пакета не подразумевает добавления функций или патчей к существующим багам. Это задача разработчиков пакета.

Если баг или особенность не входит в компетенцию Arch, посмотрите также Reasons for not being a bug.

Reasons for not being a bug

• Something you would like a piece of software to do, which is not implemented by the upstream developers. In short : a new feature.
• A bug already reported upstream.
• A bug already fixed upstream but not in Arch because the package is not up-to-date.
• A package which is not-up-to-date. Use the Flag Package Out-of-Date feature on Arch's packages website.
• A package which does not use Fedora, Ubuntu or some other community patch. Patches should be submitted upstream.
• A package where non essential function X or function Y is not activated. This is a feature request.
• A package which does not include a .desktop file or icons or other freedesktop stuff. This is not a bug if such files are not included in the source tarball, and this must be requested as a feature request upstream. If such files are provided by upstream but not used in the package then this is a bug.

Причины, по которым функция не является функцией

• Когда это ошибка ...
• Когда это не входит в зону ответственности Arch, например свойство upstream.
• Пакет не является актуальным. Используйте функцию Пометить Пакет как Устаревший на сайте пакетов Arch.
• Пакет, который не использует патчи Fedora, Ubuntu или патчи других сообществ. Патчи должны быть отправлены в upstream.

Gather useful information

Here is a list of useful information that should be mentioned in your bug report :

• Version of the package being used.

• Version of the main libraries used by the package (available in the depends variable in the PKGBUILD), when they are involved in the problem. If you do not know exactly what information to provide then wait for a bug hunter to ask you for it ...

• Version of the kernel used if you are having hardware related problems.

• Indicate whether or not the functionality worked at one time or not. If so indicate since when it stopped working.

• Indicate your hardware brand when you are having hardware related problems

• Add relevant log information when any is available. This can be obtained in the following places depending on the problem :
  • /var/log/messages for kernel and hardware related issues.
  • /var/log/Xorg.0.log or /var/log/Xorg.2.log or any Xorg like log files if video related problems (nvidia, ati, xorg ...)
  • Run your program in a console and use verbose and/or debug mode if available (see your program documentation), and copy the output in a file. When running an application in a terminal make sure relevant information will be displayed in english so that many people can understand it. This can be done by using export LC_ALL="c". Example with a software named foobar from which you would like to have relevant information at runtime and provided that foobar has a --verbose option :

someone@somecomputer # export LC_ALL="C"
someone@somecomputer # foobar --verbose

This will affect only the current terminal and will stop taking effect when the terminal is closed.

If you use a pastebin to paste any relevant information, it is preferable not to use rafb.net as pastes there last only for 24 hours.

• Indicate how to reproduce the bug. This is very important, it will help people test the bug and potential patches on their own computer.

• The stack trace. It is a list of calls made by program during its execution, and helps in finding part of program where the bug is located, especially if bug involves the program crashing. You can obtain a stack trace using gdb (The GNU Debugger) by running the program with "gdb name_of_program" and then typing "run" at the gdb prompt. When the program crashes, type "bt" at the gdb prompt to obtain the stack trace and then "quit" to exit gdb.

Открытие Ошибки

When you are sure it is a bug or a feature and you gathered all useful information, then you are ready to open a bug report or feature request.

Создание аккаунта

Вы должны создать аккаунт в Системе Отслеживания Ошибок Arch. Это также просто, как создание аккаунта на вики или на форуме, ничего трудного или важного здесь нет. Не бойтесь писать свой адрес электронной почты : он будет скрыт и вы будете получать письма только по тем ошибкам, за которыми вы следите.

Проекты и Категории

Once you have determined your feature or bug is related to Arch and not an upstream issue, you will need to file your problem in the correct place (watch the project name in the drop down list to the left of 'Switch' button in top left corner of bug report creation page.):

• Arch Linux - for packages in testing, core, or extra. It is also a place for documentation, websites (except AUR), and security issues.

• Arch User Repository (AUR) - for the website and the tools used to manage packages in community and unsupported. It is not a place for software in community or unsupported.

• Community Packages - for packages in community. It is not a place for packages in unsupported.

• Pacman - for pacman and the official scripts and tools associated with it. This includes things like makepkg and abs; it does not include community-developed packages such as yaourt.

• Release Engineering - intented for all release related issues (isos, installer, etc)

There is no place for reporting problems with packages in unsupported. AUR provides a way to add comments to a package in unsupported. You should use this to report bugs to the package maintainer.

Серьезность

Выбор critical в статусе серьёзности не поможет быстрее исправить ошибку. Это только приведет к тому, что действительно серьёзные проблемы станут менее заметны. Ещё возможно, что разработчик будет меньше хотеть исправлять эту ошибку.

Вот примерная шкала серьёзности ошибок:

• Critical — System crash, severe boot failure that is likely to affect more than just you, or an exploitable security issue in either a core or outward-facing service package.
• High — Основная работоспособность программы нарушена; менее серьёзные проблемы безопасности, и т.д.
• Medium — Некритические возможности программы неисправны или не соблюдены стандарты UNIX.
• Low — Дополнительная функциональность не работает(отдельный plugin или всё вместе с ним).
• Very Low — Ошибка в переводе или документации. Что-то что не имеет большого значения, но необходимо отметить для исправления в будущем.

Including Relevant Information

This is maybe one of the most difficult parts of bug reporting. You have to choose from the chapter Gather useful information which information you will add to your bug report. This will depend on which your problem is. If you do not know what the relevant pieces of information are, do not be shy : it is better to give more information than needed than not enough.

A good tutorial on reporting bugs can be found at [1]

However, developers or bug hunters will ask you for more information if needed. Fortunately after a few bug reports you will know what information should be given.

Short information can be inlined in your bug report, whereas long information (logs, screenshots ...) should be attached.

Following up on Bugs

Do not think the work is done once you have reported a bug!

Developers or other users will probably ask you for more details and give you some potential fixes to try. Without continued feedback, bugs cannot be closed and the end result is both angry users and developers.

Voting and Watching

You can vote for your favorite bugs. The number of votes indicates to the developers how many people are impacted by the bug. However, this is not a very effective way of getting the bug solved. Much more important would be posting any additional information you know about the bug if you were not the original reporter.

Watching a bug is important- you will receive an email when new comments are added or the bug status has changed. If you opened a bug verify that the "Notify me whenever this task changes" checkbox is activated in order to receive such emails.

Answering additional information requests

People will take the time to look at your bug report and will try to help you. You need to continue to help them resolve your bug. Not answering to their questions will keep your bug unresolved and likely hamper enthusiasm to fix it.

Please take the time to give people more information if requested and try the solutions proposed.

Developers or bug hunters will close your bug if you do not answer questions after a few weeks or a month.

Updating the bug report when a new version of the related software is out

Sometimes a bug is related to a given package version and is fixed in a new version. If this is the case then indicate it in the bug report comments and request a closure.

Closing when solved

Sometimes people report a bug but do not notify when they have solved it on their own, leaving people searching for a solution that has already been found. Please request a closure if you found a solution and give the solution in the bug report comments.

Больше о статусах ошибок

В течении своей жизни, ошибка проходит несколько статусов :

• Unconfirmed : Это состояние по умолчанию. Вы только что сообщили о ней, никому пока не удалось воспроизвести проблему и подтвердить, что это действительно ошибка.

• New : The bug is confirmed but it has not been assigned to the developer responsible for the related software. It is usually the case when more investigation is needed to determine which software is responsible for the bug.

• Assigned : The bug has been assigned to a developer responsible for the software involved in the bug. It does not mean that the developer will be the one who will fix the bug. It does not even mean that the developer will work on a solution. It just mean that the developer will take care of the life cycle of the bug, including reviewing patches if any, releasing a fix and closing the bug when required. There is no point at contacting a developer directly to have a bug fixed more quickly, he/she will certainly not like it ...

• Researching : Somebody is looking for a solution. This status is rarely used at Arch and it is better this way. The researching status could make people believe they do not need to get interested in the bug report. But usually we need more than one person to fix a bug : having several experienced people on a bug help a lot.

• Waiting on customer and Requires testing : The one who reported a bug is asked to provide more information or to try a proposed solution, but he/she did not give a feedback yet. Those status are rarely used at Arch and should be used more often. However this is important that you watch the bug (see the voting and watching section) as developers or bug hunters usually ask questions in the comments.

• A task closure has been requested : this is not exactly a status, but you may found some bug reports with such a notification. This indicates that somebody requested a closure for the bug. A reason is added to the request most of the time. It is upon the assignee developer to decided whether he/she will accept the closure or not.

• Closed : Either this is not a valid bug (see Reasons for not being a bug) or a solution has been found and released.

Some people (developers, TUs ...) are responsible for dispatching the bugs and change their status.

Отлов Ошибок

День Уничтожения Ошибок

Bug Squashing Day

Внешние Ссылки

How to Report Bugs Effectively