Bugzilla
Z Mandriva Poland
Błędy znalezione w systemie Mandriva Linux można zgłaszać na stronie qa.mandriva.com
Zanim zgłosisz błąd, sprawdź czy nie został on uwzględniony w Erracie do systemu (zobacz: Mandriva_Linux_2009.0_Errata). Przeglądnij także błędy, które już zostały zgłoszone (skorzystaj z wyszukiwarki Bugzilli).
Ta strona zawiera informacje o prawidłowych procedurach w zgłaszaniu błędu stwierdzonego w dystrybucji Mandriva Linux. Proszę ją przeczytać i wykonać je przy zgłaszaniu błędów, a pomoże to nam zwiększyć efektywność procesu rozwiązywania błędów.
Spis treści |
System śledzenia błędów
Jest jedno centralne miejsce do raportowania błędów Mandrivy: http://qa.mandriva.com. Używa ono popularnego "open source'owego" (opartego na otwartym źródle) systemu śledzenia błędów o nazwie Bugzilla.
Przed wysłaniem nowego błędu
Po pierwsze, będziesz potrzebować Bugzilla. Bugzilla nie używa kont my.mandriva wykorzystywanych przez wiele innych usług Mandrivy. Właściwe konto możesz założyć na pierwszej stronie Bugzilli.
Dalej, spróbuj ustalić czy rzeczywiście powinieneś zgłosić dostrzeżony przez ciebie problem. Najpierw sprawdź, czy nie jest on już zgłoszony przez kogoś innego.
Przeszukaj Bugzillę
Przeszukaj Bugzillę by mieć pewność, że podobny problem nie został już wcześniej zgłoszony i że pozostaje on wciąż nierozwiązany.
Domyślnie, Bugzilla nie przeszukuje listy ROZWIĄZANYCH problemów. Można to wymusić. Aby to zrobić wprowadź dużymi literami słowo ALL przed zapytaniem, np.: ALL rpmdrake. Możesz w ten sposób odkryć, czy błąd nie został już rozwiązany i poprawiony w późniejszym wydaniu.
Jeśli nie jesteś zaznajomiony z Bugzillą, przynajmniej wejdź na listę Bugzilli wszystkich zgłoszonych dla danego programu błędów oraz przeszukaj listy z podsumowanymi wynikami błędów.
Zobacz również na stronie Erraty Mandriva Linux wydania którego używasz czy problem jest tam wymieniony.
Jeśli znajdziesz podobny problem do Twojego, dodaj swój e-mail w odpowiednim polu CC obok innych i dodaj opis swojego problemu w komentarzach. Pozwala to uniknąć wielokrotnych raportów o tych samych błędach. Jeden zwięzły i pełny raport o błędzie daje lepszy obraz danego problemu niż kilka pojedynczych odrębnych raportów o tym samym błędzie.
Używaj najnowszego pakietu
Należy upewnić się czy używasz najnowszej wersji dostępnego pakietu. Jeśli używasz Cookera, powinieneś już wiedzieć, jak utrzymać swój system aby był w bieżącej, aktualnej wersji. Jeżeli używasz wydania stabilnego, postępuj zgodnie z instrukcjami: instalowanie aktualizacji aby być pewnym, że masz aktualny system, Następnie upewnij się przed zgłoszeniem błędu, że problem nadal występuje i nie jest rozwiązany.
Czy to właściwe?
Sprawdź, czy twoje sprawozdanie o błędzie jest tym, które obsługuje system błędów Mandrivy. Istnieją dwa rodzaje problemów, dla których system błędów Mandrivy jest odpowiednim miejscem dla ich załatwienia. Pierwszy z nich to przypadki, w których składnik dystrybucji Mandriva Linux nie działa zgodnie z przeznaczeniem w taki sposób, że problem może być skutecznie rozwiązany przez zespół rozwoju Mandrivy. Drugi to propozycje usprawnień odnoszące się do aplikacji rozwijanych przez zespół rozwoju Mandrivy albo odnoszące się do pakowania innych aplikacji.
Problemy, które mogłyby być potraktowane lepiej gdzieś indziej - na przykład, przez oryginalnych twórców aplikacji - nie powinny być zgłaszane do systemu błędów Mandriva. Nie powinny również być tu zgłaszane propozycje usprawnień odnoszące się do produktów nie opracowanych przez zespół rozwoju Mandriva: te powinny być przesyłane do odpowiednich deweloperów.
Czy to jest obsługiwane?
Wszystkie raporty o błędach powinny odnosić sie do obsługiwanych (wspieranych) wersji programów. Listy: Mapa długotrwałości zawierają wykazy aktualnie wspieranych wydań oraz podają długości czasu, przez jaki poszczególne wersje programu będą wspierane. Jeśli edycja (wersja) nie jest tam wymieniona, oznacza to, że nie jest już obsługiwana. Jest małe prawdopodobieństwo, aby raporty dotyczące produktów, które nie są już obsługiwane były rozpatrywane.
Zgłaszanie błędów w nowym raporcie
Jeśli podczas przeszukiwania danych w Bugzilli upewniłeś się, że twój raport o błędzie jest pierwszym na ten temat, to następnie zwróć uwagę aby w swym raporcie umieścić potrzebne informacje:
Właściwa dystrybucja
Wybranie i podanie właściwej Dystrybucji (release) jest pierwszym krokiem do złożenia sprawozdania o błędzie. Powinna być podana ta Dystrybucja która jest rzeczywiście używana na komputerze z systemem, w którym istnieje problem z oprogramowaniem.
Należy pamiętać, że wszystkie snapshot, alpha, beta i RC liczone są jako wydania Cooker. Błędy w tych wydaniach powinny być złożone jako do dystrybucji Cooker. Proszę również podać w raporcie, którego dokładnie wydania używasz.
Poprawna nazwa produktu, komponentu składowego, wersji
Należy podać odpowiednią, poprawną nazwę produktu, części i wersji w której występuje błąd.
- zidentyfikować który pakiet RPM zawiera program z błędem
- można się dowiedzieć, który pakiet RPM zawiera dany plik za pomocą komendy: rpm -qf problematyczny plik
- więcej informacji o pakiecie RPM dostępnych jest przy użyciu: rpm -qi nazwa pakietu
Jeśli nie można zidentyfikować której dokładnie wersji pakietu dotyczy dostrzeżony przez ciebie błąd, nie powinno to powodować zaniechania zgłoszenia błędu. Określ w możliwie najlepszy sposób wersję programu z błędem i dodaj notatkę w opisie błędu stwierdzając, że nie jesteś pewny, czy jest on złożony przy prawidłowym produkcie. Podczas sortowania zespół Mandrivy pomoże określić o jaką wersję produktu chodzi i przekaże raport do właściwego opiekuna pakietu.
Szczegóły
Szczegóły są ważne. W przypadku gdy masz wątpliwości, staraj się dostarczać raczej więcej informacji niż za mało.
- znajdź wersję pakietu RPM oprogramowania: rpm -q nazwa-pakietu
- wyjaśnij Twój problemu ze sprzętem o ile taki występuje:
- lspcidrake -v dostarcza użytecznych informacji na temat sprzętu w samym komputerze, jak też podłączonego przez PCI, PCI-E i AGP sprzętu zewnętrznego.
- lsusb zawiera przydatne informacje na temat sprzętu USB
- lsmod zapewnia pełną listę sterowników załadowanych w systemie
- zawsze podaj, czy używasz wersji i586 lub x86-64 dystrybucji
- opisz dokładnie okoliczności w jakich wystąpił błąd (co było robione, działo się w systemie i wywołało wystąpienie błędu).
- staraj się skracać swój opis do kroków wiodących do najmniejszego pliku z którym jest problem oraz najmniejszego zestawu działań które wywołały błąd, co w sensowny i zwięzły sposób umożliwiałoby i pomagało innym w określeniu przyczyn występującego problemu.
- dodaj wszelkie informacje na temat zmian dokonanych przez ciebie w konfiguracji
Jeśli sprawozdanie błędu jest złożone bez wystarczających informacji, osoba segregująca w zespole ustawi jego status NEEDINFO i opublikuje komentarz wyjaśniając, jakie dalsze informacje są wymagane. Jeżeli tak się stanie w przypadku przedłożonego przez ciebie raportu o błędzie, koniecznie dostarcz brakujące informacje.
Załączniki do raportów o błędach
Raporty Bugzilli są niestety ograniczone w długości co wynika ze szczegółów funkcjonowania interfejsu WWW Bugzilli. Może się jednak okazać, że będziesz musiał złożyć długi raport o błędzie w kilku kawałkach, lub użyć załącznika.
Jeśli masz plik z danymi, które są związane z Twoim problemem (np. pliki MP3, które nie działają pod xmms), możesz dołączyć go do swojego raportu o błędzie w załączniku. Jest ogólnie przyjęte, że pliki konfiguracyjne o dość dużych długościach są zamieszczane jako załączniki, ponieważ czyni to je łatwiejszymi w obsłudze.
Po przedstawieniu błędu
Gdy twój raport o błędzie zostanie złożony, to następnie będzie rozpatrzony zgodnie z polityką błędów. W skrócie oznacza to, że segregujący członek zespołu zdecyduje, czy jest to ważny raport, który wymaga uwagi opiekuna. Określi również, czy dane zawarte w raporcie są wystarczająco szczegółowe i w miarę potrzeby zwróci się z prośbą do Ciebie jako do osoby raportującej o dalsze informacje. Następnie błąd zostanie przydzielony do odpowiedniego opiekuna celem rozwiązania.
Rozwiąż sam swój problem
Próbuj wszystkich środków, by rozwiązać swój problem i naprawić błąd samodzielnie! Cechą oprogramowania open source jest to, że nie trzeba czekać na nikogo by poprawiać błędy - można to zrobić samodzielnie (lub wynająć kogoś by to zrobił).
Gotowe poprawki oprogramowania kodu źródłowego są mile widziane, ale nie wahaj się dodawać nawet niedokończone lub częściowe rozwiązania do swojego raportu o błędzie. Mogą one pokazać bardziej precyzyjnie, gdzie jest problem.
Jeśli zdołasz skutecznie "załatać" problem, dodaj swoje poprawki do swojego raportu błędów (może to być jako późniejszy komentarz do raportu).
