Ver código

=Bugzilla=

----
ATENÇÃO: Esta página ainda não está totalmente traduzida, agradecia que alguém a fosse traduzindo.
----

==General Bug Handling==
Este documento descreve como usar o [http://bugzilla.novell.com bugzilla em bugzilla.novell.com].

===Que campos devem ser preenchidos inicialmente? Quais devo mudar ou não?===
* Component (Componente)<br>Nota: nem todos os defeitos durante a instalação são por culpa do Yast, podem ser, por exemplo, defeitos do kernel.
* Platform (Plataforma)<br>Escolha "todos" se acha que não depende da plataforma, senão, escolha a sua plataforma.
* Summary (Sumário)<br>As pessoas que escrevem aqui devem entender o que se passa.
* Bug description (Descrição do defeito)<br>Escreva todos os detalhes sobre o defeito. Note que não deve dizer "Ver sumário" visto que o sumário pode mudar.
* How to Reproduce? (Como Reproduzi-lo?)<br>Isto é tão importante que merece uma explicação extra em P:[[#People got mad at me because I entered "Install SUSE x.y-Beta-z" in Bugzilla's "how to reproduce" field. Why?|1.1.5]]
* Severity (Gravidade)<br>Escolha a gravidade certa. Marque-o apenas como "blocker" se acha que não devemos esquecê-lo neste producto.
* The rest (O resto)<br>Não precisa de preencher os outros campos, os valores predefinidos estão bem.

===Serei informado depois de reportar o defeito?===
Sim, se as suas "prefs" não estiverem mudadas, será informado via email sobre quaisquer alterações.

Se está com dúvidas ou apenas acha que precisa de comentar qualquer resposta, por favor não envie nada para o endereço de comentador que é gerado automaticamente no mail do bugzilla. Deve usar a interface web do bugzilla para comunicar porque é a única maneira da informação relevante ser acessível a todos os interessados.

===Quais campos devo mudar e quais não devo?===
Como não-desenvolvedor, deve em geral apenas adicionar comentários adicionais, ou adicionar-se ao CC. Se o defeito está especificado como "NEEDINFO" (PRECISAdeINFORMAÇÃO) lembre-se de especificá-lo como "ASSIGNED" (ATRIBUIDO) depois de dar toda a informação.<br>
Que? Há uma caixa de verificação, por baixo do comentário, que diz algo como "This comment provides the needed info" (Este comentário contém a informação necessária) - não deverá ser usado preferivelmente?

===Que devo fazer se a versão actual do openSUSE conter o mesmo (ou um parecido) defeito que já existia mas que já foi reportado para uma verao enterior?===
Sugerimos que mova a versão do pacote e escreva no comentário algo como "Este defeito foi reportado para o openSUSE x.y e continua a existir para o openSUSE u.v. Estou apenas a avisar que o defeito ainda existe.". Se o defeito já foi fechado anteriormente, deve reabri-lo.


===People got mad at me because I entered "Install SUSE x.y-Beta-z" in Bugzilla's "how to reproduce" field. Why?===

Porque esta é informação completamente inútil - redundante e não ajuda em nada em   reproduzir um bug. Nós podemos dizer que um erro é sobre a instalação porque você selecionou "Installation" na lista de componentes de Bugzilla, e nós podemos dizer que versão você instalou da lista de  versões ao lado.

What we really need to know is what you did and how you did it - like "boot from CD1, select "Installation", select language "Klingon", leave the installation settings as they are, confirm installation, watch as your hard disk goes up in flames."


And no, this really, really isn't nitpicking - we have so many installation modes and so many installation paths that it takes ages to figure all that out from the log files. You have that information readily available, so please enter it at that field.


Claro que nós não precisamos que o nível de detalhamento quando você estiver reportando um bug sobre um texto de ajuda em um dos diálogos finais da configuração de hardware (como impressora, placa de TV, etc.) - mas os passos para se chegar onde o problema ocorreu nós realmente precisamos. Nos temos tantos opções diálogos que não é fácil descobrir qual deles você escolheu

===People were very unhappy because I only wrote "see subject" in the Bugzilla bug description - but my subject really explains it all! Isn't it pure nitpicking to insist on bug reporters repeating that in the description field?===


No, not at all.

Subjects get changed all the time. The problem you reported might only be the tip of an ice berg - the real problem might be at a completely different place, and then those knowing that place of course will change the subject accordingly. This in turn means that your original subject will get lost.

So it should be obvious enough that the subject is no place to store relevant information, and the problem that is being reported certainly is the single most important information in a bug report.

It is also simply bad style to dump all kinds of information in the subject and then only reference to the subject. This is just pure laziness. It costs you time once to do it properly, but everybody working with that bug has to search all over the place for the relevant information again and again.

In addition to that, a subject should be concise - but a bug description should be explanatory. Both requirements are contradictory.

==Bug Status NEEDINFO==

===What does that NEEDINFO bug status mean, and how should this be handled?===
	

<tt>NEEDINFO</tt> means that the bug owner (the person who is currently working on that bug) needs more information about that bug - usually from the bug reporter.

If you find a bug you reported is set to <tt>NEEDINFO</tt>, look for a question or a request to supply more information (such as logs etc.) in one of the last comments.

If this is the case, please answer that question or provide that information, respectively, and set the bug status to <tt>ASSIGNED - click on Accept bug (change status to ASSIGNED)</tt> in the Bugzilla bug details page.

Please prefer bugzilla web interface for answering questions and attaching logs. Do not send this information by email unless you have serious reasons to do so. There are usually more people working on one bug and this information should be accessible for all of them to ensure quick fix.

===Don't I become the bug owner when I change a bug's status away from <tt>NEEDINFO</tt> to <tt>ASSIGNED</tt> (with <tt>Accept bug</tt> (<tt>change status to ASSIGNED</tt>) in the Bugzilla bug details page)?===
	

No, the bug owner remains the same, only the status changes. You can safely do that without fear that this bug will become your responsibility because of this.


===Why is it important that I set a bug status away from <tt>NEEDINFO</tt> to <tt>ASSIGNED</tt>? Isn't that the bug owner's responsibility?===
	

No, this is the responsibility of whoever answers the question that was asked or supplies the information that was requested.

Bug owners use <tt>NEEDINFO</tt> so they can more easily see what bugs they can actually work on (those set to <tt>ASSIGNED</tt>, <tt>NEW</tt>, or <tt>REOPENED</tt>) and which ones are stuck because important information is missing - <tt>NEEDINFO</tt> bugs no longer appear in their to-do list of open bugs.

This is why it is important that the bug status is set away from <tt>NEEDINFO</tt> to some other status - the bug owner might overlook the mail Bugzilla sends automatically for comment added to a bug, and then this bug might remain in status <tt>NEEDINFO</tt> for an indefinite period of time.

Our maintainers receive so many generated mails that at peak times (like during a Beta phase) they cannot reasonably react to each one individually, so at a certain point they have to resort to bug status lists - and then chances are that it is overlooked that some requested information is now available and work on a bug can resume.

So it is in the own interest of each bug reporter to change the bug status away from <tt>NEEDINFO</tt> after the questions are answered.

Of course, sometimes you can be lucky and the bug owner realizes that the requested information is now available and sets the bug status to <tt>ASSIGNED</tt> himself, but relying on luck is usually not a good tactic.

Please note that bugs which are assigned to the BNC-Screening-Team (mainly YaST- and X11-related problems) initially or during the process should not be set from <tt>NEEDINFO</tt> to <tt>ASSIGNED</tt> by the reporter or the person the information was requested from. This is because a change of this status almost always involves a reassignment which is done by this team. Changing this status might cause the specific bug to appear on the wrong listing and might therefore be not handled (reassigned) efficiently. Thank you for taking this into account.

==Bug Status VERIFIED / CLOSED==

===Should I mark a bug as VERIFIED or CLOSE it when I see that the problem is solved in a new version or with the updates?===
[TBD]

==Bug Status WONTFIX==

This section has been moved to [[Bug Status WONTFIX]]

=YaST=

<p id="zmd">Esta seção foi movida para [[Bugs/YaST]]<br>
Isto inclui dependencias, libzypp, ZENWorks, registro.</p>

=Kernel Bugs=

Esta seção foi movida para [[Bugs/Kernel]]

= SUSE Linux Documentation =

Report SUSE Linux documentation defects in Bugzilla (component: "Documentation") and for release products also add entries to [[Errata in the openSUSE 10.3 Documentation]].

=Beta Testing=

==I'd like to participate in testing betas for SUSE Linux. Whom shall I contact?==
	

openSUSE is open. Just subscribe to the [[Communicate#openSUSE_Project_Mailing_Lists|openSUSE Project Mailing Lists]] and report your Bugs like described in [[Submitting Bug Reports]].

==I'd like to participate in testing betas for other products like SLES or SLED. Whom shall I contact?==
	

Not all these products have beta programs, but if they do have, they might be accessible via [http://www.novell.com/beta/index.jsp The Novell Beta Program].

==Que tipo de respostas voces querem?==
	

Nós gostamos de receber respostas tanto positivas quanto negativas - e tambem idéias para melhorias.

Respostas positivas siguinificam que nós gostamos de ouvir que um sistema foi instalado e funcinando com sucesso, que certas areas tem sido testadas e que elas funcionam. Por favor report isto em  [mailto:openSUSE@opensuse.org]. Esta resposta positiva e gravada em nosso testdb.

For negative feedback which means any problems that are encountered, we use Bugzilla. Please file a separate bug report for each problem that you encounter. There are other areas in this FAQ that explain in detail how to file a bug report.

Additionally ideas for improvements, commonly called feature requests, are wanted. There are special pages [[Package Wishlist]] and [[Feature Wishlist]] to add those ideas.

==What is [http://betatestdb.suse.de betatestdb.suse.de]?==
	

'''Note:''' betatestdb.suse.de was last updated for SUSE Linux 10.0 and access to it is password-protected. (The login you use for this wiki and bugzilla won't work.)


Betatestdb is a tool to see which packages have been tested by beta testers and if the tests have been successfull or not. This allows us to receive not only negative feedback (something is broken) via Bugzilla but also positive feedback that the packages are working and the product is stable.

For a large number of packages there are detailed testcases which contain a description what to do - either a special feature or the whole software package. Please follow these instructions and enter the results in betatestdb.

Note: To have a better view onto the packages, we separated the packages into different areas.


[[Category:Developer]]

[[de:Fehlerberichterstattung HGF]]
[[es:Bug_Reporting_FAQ]]