Como relatar um bug

O objetivo deste documento é fornecer instruções passo a passo sobre como relatar bugs no Fedora.

Um bug de software não precisa necessariamente ser uma falha de software. Qualquer comportamento indesejado observado no software deve ser relatado como um bug. O mantenedor do pacote pode então olhar o relatório de bug e decidir o melhor curso de ação.

Todos devem relatar os bugs: Todos os usuários são incentivados a registrar os bugs que encontrarem. A ação de relatar de bugs não se limita apenas a desenvolvedores de software.

Terminologia

Existem alguns termos que são comumente usados neste documento:

  • Bug: Um bug é qualquer comportamento em um software que parece inesperado/indesejado.

  • Rastreador de bugs: O sistema de rastreamento de bugs do Fedora em https://bugzilla.redhat.com.

  • Pacote: Cada software que está disponível no Fedora tem um nome de pacote formal que é usado pelo rastreador de bug e outras ferramentas de infraestrutura. Os pacotes podem ser pesquisados usando o Fedora dist-git.

  • Mantenedor: Um corpo de voluntários que cuidam dos pacotes de software fornecidos no Fedora. Eles são chamados de "mantenedores de pacotes". Eles acompanham os bugs, ajudam com problemas e geralmente agem como intermediários entre os desenvolvedores do software e os usuários do Fedora.

  • QA: Garantia de qualidade é o processo de garantir que o software funcione conforme o esperado.

  • Bodhi: O aplicativo web de QA do Fedora.

Antes de relatar um bug

Etapa 1: Verifique a versão mais recente

Conforme os bugs são relatados e corrigidos, os desenvolvedores coletam um conjunto de correções e lançam periodicamente versões aprimoradas de seus softwares. Portanto, antes de relatar um problema, é útil verificar se você está usando a versão mais recente de um software. A maneira mais simples de obter a última versão do software no Fedora é atualizar regularmente o seu sistema. Os usuários do GNOME/KDE e outros ambientes gráficos podem usar seus aplicativos padrão para fazer isso. Eles verificam periodicamente se há atualizações e notificam os usuários. Você também pode usar o gerenciador de pacotes padrão dnf para verificar e atualizar seu sistema. Apenas usuários com privilégios de administrador podem fazer isso:

$ sudo dnf update --refresh

Etapa 2: Verifique se o bug já foi relatado

Se você estiver usando a versão mais recente do software disponível no Fedora, é provável que o bug não tenha sido relatado ou tenha sido relatado, mas uma correção ainda não foi lançada. Portanto, é útil pesquisar a lista de bugs já relatados antes de preencher um novo relatório. O aplicativo web Fedora Packages lista os bugs relatados atualmente para todos os pacotes. Também existe um atalho conveniente que pode ser usado.

https://bugz.fedoraproject.org/<nome do pacote>

Aqui, o nome do pacote deve ser o nome formal do pacote.

20180825 how to file a bug gs bugs
Figure 1. O aplicativo web Fedora Packages lista os relatórios de bugs do GNOME Software em https://bugz.fedoraproject.org/gnome-software.

Como pode ser visto na imagem, o aplicativo web Fedora Packages também fornece outras informações sobre um pacote.

Encontrando o nome do pacote: Se você não sabe o nome formal do pacote do software, você pode usar o aplicativo web Fedora Packages para procurá-lo e ver a lista de bugs lá.
20180825 how to file a bug gs
Figure 2. Procurando no aplicativo web Fedora Packages pelo GNOME Software.
Pesquisa avançada: você também pode usar os recursos de pesquisa avançada do rastreador de bug para restringir sua pesquisa. No entanto, isso não é necessário.

Se um relatório de bug já foi preenchido descrevendo o problema, você deve fornecer qualquer informação extra que possa ter. Se não houver mais nada a acrescentar ao relatório, você deve adicionar a si mesmo em "CC" (cópia carbono) no relatório para receber quaisquer atualizações. Isso pode ser feito clicando no botão "Save changes" (salvar alterações) quando a opção "Add me to CC list" (Adicionar-me à lista de CC) estiver marcada, conforme mostrado abaixo:

20180825 how to file a bug cc list
Figure 3. A lista CC contém todos os usuários que devem ser notificados quando alguma atualização for feita no relatório.

Relatando um bug

Etapa 0: Crie uma conta no Bugzilla

Use sua conta Fedora: Você pode usar sua conta Fedora para entrar no Bugzilla. Isso é preferível, pois sua conta Fedora também pode ser usada para entrar em todos os outros serviços do Fedora.

Os bugs são relatados na instância do bugzilla do Fedora, e você deve ter uma conta lá para registrar os bugs ou interagir com eles. Uma conta requer um endereço de e-mail válido e pode ser criada aqui (clique em "Register"). O rastreador de bugs só enviará notificações por e-mail sobre bugs em que o usuário esteja envolvido. Nenhum outro e-mail será enviado.

Etapa 1: Relatar um novo bug

Se um relatório de bug para um problema específico ainda não tiver sido preenchido, você deve enviar um novo. A maneira mais fácil de enviar um novo relatório é usando a lista suspensa "File a new bug" (Relatar um novo bug) na barra do lado direito do aplicativo web Fedora Packages.

20180825 how to file a bug new bug shortcut
Figure 4. O aplicativo web Fedora Packages fornece um atalho conveniente para relatar novos bugs.

This redirects to a new bug report template on the bug tracker. The image below shows a new bug template:

20180825 how to file a bug new bug
Figure 5. A new bug report template.

The following fields need to be set:

  • Component: This will be set to the name of the package.

  • Version: You should set this to the version of Fedora that you observed the bug on.

  • Summary: You should provide a useful short summary of the issue here.

  • Description: More detailed information about the issue should be provided here. It already contains a template, which is explained below.

  • Attachment: Files that provide more information of the issue can be uploaded with the bug report using the button here. E.g,, screen-shots, log files, screen recordings.

  • Severity, Hardware, OS: These fields are optional and need not be set.

Description of problem:

Explain the issue in more detail here.

Version-Release number of selected component (if applicable):

The version of the package should be specified here. Once the package name is known, the version can be obtained by using the rpm command:

$ rpm -q <packagename>

For example:

$ rpm -q gnome-software
gnome-software-3.28.2-1.fc28.x86_64

How reproducible:

How often is the issue observed? Usually, a good answer to this field is one of:

  • Always: the issue is observed each time.

  • Sometimes: the issue occurs, but not each time.

  • Only once: the issue was only observed once.

Issues that occur always are easiest for developers to diagnose, since they may also be able to replicate it on their machines to collect more information. If an issue only happens sometimes, developers must spend more time and effort to understand what causes the problem. If an issue was only observed once, it is even harder to debug.

Detailed bug reports make bugs easier to fix: If possible, you should try to investigate what steps cause the issue to happen and provide these steps in the next section:
Submit a report even if unsure: If you aren’t sure of what to fill in, you should still submit the bug report. Maintainers can follow up with questions to gather more information.

Steps to Reproduce:

These enable other users to verify the bug, and they also inform the developers of what specific steps cause the issue. It makes it much easier for them to look at the source code and pick out the bits that may be faulty.

Actual results:

What is observed when the issue occurs?

Expected results:

What does the user expect that should happen if the software behaved correctly?

Additional info:

Any additional information that may be useful to the maintainer should be added here.

Step 2: Follow up on filed reports

After a bug has been filed, you should keep an eye out for any updates. An e-mail notification of any new comments to the report will be sent to everyone involved in the bug report---the reporter, other users, and the maintainer. Often, maintainers will comment with queries to gather more information on the issue. Sometimes other users that experience the same issue may also add more information.

Ask for instructions: If the maintainers ask for more information but it is unclear how it should be gathered, it is perfectly OK to ask the maintainers for explicit instructions.
E-mail notifications: The notifications are sent from bugzilla@redhat.com. You should keep an eye out for e-mails from this address, and add it to your "no-spam" lists.

If no updates are made to the bug in a week or two, you should also feel free to comment asking for any information. Sometimes maintainers who receive many bug reports can miss notification e-mails. A polite comment will send them a new notification.

Step 3: Test updates

A well reported bug will usually be fixed, and the maintainer will make an improved version of the software available to Fedora users. Bodhi will add a comment to the report when this happens. You can help the maintainer by confirming if the improved version works better in the Bodhi.

20180825 how to file a bug qa
Figure 6. Bodhi Application adds comments informing users of an update that should fix the bug.
Help test updates: All users can help by testing new versions of software. More information on this can be found here. Note that this requires a Fedora account.

Once the improved version of the software has passed the QA process, the bug will automatically be closed. Congratulations!