Bug Reporting FAQ

Generalna obsługa błędów

---

Dokument ten opisuje jak korzystać z bugzilla na bugzilla.novell.com.

Które pola powinny być wstępnie wypełnione? Które powinny zostać zmienione a które nie?

• Komponent
  Notka: nie wszystkie błędy podczas instalacji są winą YaST, może to być np. wina jądra.
• Platforma
  Użyj “all" jeśli sądzisz że jest to niezależne od platformy, w innym przypadku określ swoja platformę.
• Podsumowanie
  Osoby patrzące na podsumowanie powinny rozumieć o co chodzi.
• Opis błędu
  Opisz wszystkie szczegóły błędu. Zauważ że nie powinno się pisać "patrz podsumowanie" dlatego że może ono ulec zmianie.
• Jak to powtórzyć?
  Tojest na tyle ważne że wymaga dodatkowego wytłumaczenia Pytanie: 1.1.5
• Dotkliwość
  Wybierz odpowiednią dotkliwość błędu. Zaznacz go jako “blocker" jeśli blokuje on pracę na produkcie. Znacznik SHIP_STOPPER jest dostępny, jeśli uważasz że nie powinnyśmy wypuścić produktu z tym nienaprawionym błędem.
• Reszta
  Nie musisz wypełniać innych pól, domyślne wystarczą.

Otrzymam jakiś odzew po raporcie błędu?

Tak, jeśli twoje preferencje nie zostały zmienione, zostaniesz poinformowany o jakichkolwiek zmianach przez e-mail.

Jeśli jesteś pytany lub czujesz że powinieneś odpisać na pozostawiony komentarz to nie wysyłaj maila na adres komentującego, który jest automatycznie generowany przez bugzille. Powinieneś używać interfejsu sieciowego bugzilli do komunikowania się ponieważ jest to jedyna droga aby istotne informacje były dostępne dla wszystkich zainteresowanych.

Które pola powinny być zmienione a które nie?

Generalnie jako nie-programista powinieneś tylko dodać dodatkowe komentarze, lub dodać siebie do CC. Jeśli błąd jest w stanie "NEEDINFO" (potrzeba więcej danych) to pamiętaj o zmianie statusu na “ASSIGNED" po dodaniu wymaganych danych.
Co? Pod komentarzami znajduje się okienko które oznajmia "This comment provides the needed info" (ten komentarz zapewnia wszystkie wymagane dane) - Nie powinno to byc najchętniej używane?

Co zrobić jeśli aktualna wersja openSUSE zawiera ten sam (lub podobny) błąd który już istnieje ale został wypełniony dla starszej wersji?

Sugeruję przeniesienie wersji pakietu i napisanie w kometarzu coś jak "ten błąd został zgłoszony dla openSUSE x.y i ciągle występuje w openSUSE u.v. Koryguję wersję". Jeśli błąd został zamknięty wcześniej, powinieneś go ponownie otworzyć.

Ludzie się na mnie obrazili bo wpisałem "Zainstaluj SUSE x.y-Beta-z" w sekcji "Jak to powtórzyć" Bugzilli. Dlaczego?

Ponieważ jest to całkiem bezużyteczna informacja - zbędna i nie pomaga w żaden sposób w zreprodukowaniu błędu. Domyślimy się że jest to błąd instalacyjny ponieważ zaznaczyłeś "instalacja" z listy komponentów Bugzilli, i widzimy jaką wersję zainstalowałeś dzięki liście wydań na prawo od tego.

Co naprawdę musimy wiedzieć to: co zrobiłeś i jak - na przykład "bootuj z CD1, zaznacz "Instalacja", zaznacz język "Klingon", zostaw ustawienia instalacyjne jak są, potwierdź instalacje, i patrz jak twardy dysk zaczyna płonąć."

Nie, to naprawdę nie jest czepianie się szczegółów - mamy tyle rodzaji i dróg instalacji że zabrało by nam wieki na domyślenie się z logów co jest nie tak. Masz informacje z łatwością dostępne, więc proszę wsadź je w te pola.

Oczywiście, nei potrzebujemy tak dokłądnych szczegółów przy raportowaniu błędół o tekście pomocnym w jednym z finalnych dialogów konfiguracyjnych (jak drukarka, karta TV, itp.) - ale kroki które prowadzą do miejsca gdzie występuje błąd są tymi które potrzebujemy. Mamy tyle dialogów że nie jest łatwym domyślenie się który masz na myśli i którą drogę obrałeś.

Ludzie byli bardzo niezadowoleni bo tylko napisałem "patrz tytuł" w opisie błędu Bugzilli - ale mój tytuł naprawdę tłumaczy wszystko! Nie jest to czepianiem się aby osoby zgłaszające błąd powtarzały to w polu "opis"?

Nie, wcale nie.

Tytuły się ciągle zmieniają. Problem zgłaszany przez ciebie może być tylko czubkiem góry lodowej - prawdziwy problem może się znajdować w całkiem innym miejscu, a wtedy osoby znające te miejsce odpowiednio zmienią tytuł co oznacza że oryginalny tytuł się straci.

Więc powinno być wystarczająco oczywiste że tytuł nie jest odpowiednim miejscem na przechowywanie ważnych informacji i zgłaszany problem jest najważniejszą informacją w raporcie błędu.

Jest również złym zwyczajem wrzucenie różnego rodzaju informacji w tytule a potem tylko referowanie do tytułu. To jest czyste lenistwo. Kosztuję cię to mniej czasu ale wszyscy pracujący nad tym błędem musza szukać odpowiednich informacji ponownie i jeszcze raz i jeszcze raz.

W dodatku, tytuł powinien być zwięzły gdzie opis błędu nie powinien wymagać tłumaczenia. Oba wymagania są sprzeczne.

Status błędu NEEDINFO

---

Co oznacza status błędu NEEDINFO, i jak powinno się z tym obchodzić?

NEEDINFO oznacz że właściciel błędu (osoba która nad nim aktualnie pracuje) porzebuje więcej informacji o tym błędzie - typowo od zgłaszającego błąd.

Jeśli jakiś błąd zgłoszony przez ciebie jest ustawiony na NEEDINFO to szukaj pytania lub żądania więcej informacji ( jak np. logi itp.) w ostatnim komentarzu.

Jeśli tak jest w tym przypadku, prosze odpowiedz na pytanie lub odpowiednio udostępnij wymagane informacje, następnie ustaw status błędu na ASSIGNED - kliknij na Accept bug (zmien status na ASSIGNED) na szczegółowej stronie błędów Bugzilli.

Preferuj interfejs sieciowy bugzilli dla odpowiadania na pytania lub dołączania logów. Nie wysyłaj tych informacji przez email chyba że masz poważne powody aby tak zrobić. Typowo więcej ludzi pracuje nad błędem i ta informacja powinna być dostępna dla każdego z nich aby zapwnic szybką poprawkę.

Nie staję się właścicielem błędu jeśli zmienię status błędu z NEEDINFO na ASSIGNED (z Accept bug (zmień status na ASSIGNED) na stronie szczegółów Bugzilli?

Nie, właściciel pozostaje ten sam, tylko status się zmienia. Możesz bezpiecznie to zrobić bez strachu o uczynienie cię odpowiedzialnym za ten błąd.

Dlaczego jest ważnym zmiana statusu błędu z NEEDINFO na ASSIGNED? Nie jest to obowiązkiem właściciela błędu?

Nie, jest to obowiązkiem każdego kto odpowiada na pytanie czy dostarcza żądane informacje.

Właściciele błędu używają NEEDINFO aby łatwo wiedzieć nad którymi błędami mogą pracować (tymi zaznaczonymi jakoASSIGNED, NEW, czy REOPENED) a które są zablokowane przez brak wymaganych informacji - NEEDINFO błedy nie pojawiają sie na ich liście "do zrobienia".

Dlatego jest ważnym aby zmienić status błędu z NEEDINFO na jakiś inny - właściciel błędu może przeoczyć email z nowym komentarzem który jest automatycznie wysyłany przez Bugzille, a wtedy ten błąd może pozostać ze statusemNEEDINFO przez nieskończony okres czasu.

Zajmujący się błędami czasem otrzymują tak dużo maili w godzinach szczytu (jak podczas fazy beta) że nie są w stanie w miarę zareagować indywidualnie dla każdego błędu, więc w pewnych momentach wolą się odnieść do listy statusów - a wtedy szanse są że zauważą zmianę statusu o dostarczeniu wymaganej informacji i wtedy mogą zacząć pracę nad tym błędem.

Więc jest to w interesie każdego zgłaszającego błąd aby zmienić status błędu z NEEDINFO po odpowiedzeniu na pytania.

Oczywiście, czasami możesz mieć szczęście gdzię właściciel błędu zauważy że wymagana informacja została dostarczona i osobiście zmienia status na ASSIGNED, ale poleganie na szczęściu nie jest zazwyczaj dobrą taktyką.

Weź pod uwagę że błędy przyznane zespołowi BNC-Screening (głównie błędy związane z YaST i X11) początkowo lub podczas procesu nie powinny być zmienianie z NEEDINFO na ASSIGNED przez zgłaszającego lub osobę od której dane były wymagane. Powodem jest zmiana przydzielenia która zawsze następuje w tem zespole przy zmianie statusu błędu. Zmiana statusu może spowodować powstanie specyficznego błędu na złej liście i może być nieprawdiłowo obsługiwana. Dziękujemy za wzięcie to pod uwagę.

Status błędu VERIFIED / CLOSED

---

Czy powinienem zaznaczyć błąd jako VERIFIED lub CLOSED jeśli widzę że problem został naprawiony w nowej wersji lub aktualizacji?

[TBD]

Status błędu WONTFIX

---

Ta sekcja została przeniesiona na Bug Status WONTFIX

Jak zgłosić błąd przeciwko...

---

Po więcej informacji jak zgłaszać błędy przeciwko błędom dla różnych komponentów jak Kernel, KDE czy Yast, skieruj się na Submitting Bug Reports

Dokumentacja openSUSE

---

Zgłoś błędy w dokumentacji openSUSE na Bugzilli (komponent: "Documentation") lub dla wydan produktów dodaj wpisy do Errata w dokumentacji openSUSE 11.0 lub Errata w dokumentacji openSUSE 10.3.

Beta Testy

---

Chciałbym uczestniczyć w beta testach SUSE Linuksa. Z kim powinienem się skontaktować?

openSUSE jest otwarte. Po prostu się zapisz na openSUSE Project Mailing Lists i zgłaszaj błędy opisane w Submitting Bug Reports.

Chciałbym uczestniczyć w beta testach innych produktów jak SLES czy SLED. Z kim powinienem się skontaktować?

Nie wszystkie te produkty mają program beta testów, ale jeśli mają, to mogą być dostępne poprzezNovell Beta Program.

Jakiego rodzaju opinii oczekujecie?

Oczekujemy pozytywnej jak i negatywnej opinii - jak również pomysłów na ulepszenia.

Pozytywna opinia oznacza że system pomyślnie się zainstalował i działa, i pewne obszary zostały przetestowane i działają. Proszę to zgłaszać na listę dyskusyjną[1]. Pozytywna opinia jest zapisywana w naszej bazie danych testów.

Dla negatywnych opinii oznaczających napotkane problemy używamy Bugzilli. Proszę wypełnić osobne raporty dla każdego napotkanego błędu. W tym FAQ znajdują się obszary opisujące w szczegółach jak zgłaszać błędy.

Dodatkowo pomysły ulepszeń, zwane żądaniami funkcji, są mile widziane. Istnieją specjalne strony Package Wishlist i Feature Wishlist aby dodawać te pomysły.

Co to jest betatestdb.suse.de?

Notka: betatestdb.suse.de była ostatnio aktualizowana dla SUSE Linux 10.0 i dostęp do niej jest chroniony hasłem. (Login którego używasz dla tego wiki i bugzilli nie zadziałają.)

Betatestdb jest narzędziem to obserwowania które paczki były testowane przez beta testerów i czy testy te wypadły pomyślnie czy nie. Pozwala nam to na otrzymywanie nie tylko negatywnych opinii (coś jest nie tak) poprzez Bugzillę ale również pozytywne opinie paczek które działają i że produkt jest stabilny.

Dla dużej liczny paczek istnieją scenariusze które zawierają opis co przetestować - albo specjalną funkcję albo cały pakiet. Postępuj proszę według instrukcji i wpisz rezutaty do betatestdb.

Notka: Aby mieć lepsze rozeznanie pakietów, rozdzieliliśmy je na różne obszary.