[OpenBSD]

Jak zgłaszać problem


Raporty o problemach z wydanymi wersjami

Zanim zgłosisz błędy/problemy w wydanej wersji, dokonaj następujących czynności:
  1. Po pierwsze sprawdź łaty i wzmianki odnoszące się do danego wydania.
  2. Następnie sprawdź, czy jest dostępne nowsze wydanie.
  3. Ostatnią rzeczą do sprawdzenia są zmiany dokonane pomiędzy wersjami OpenBSD.

Jeśli nic nie wydaje się być związane z twoim problemem, proszę zapoznaj się z sendbug(1) przed zgłoszeniem raportu o błędzie.

Przeczytaj o opisanych niżej typach raportów o błędach.

Zgłaszanie problemów z wersją -current

Jeśli twój problem jest związany raczej z kodem drzewa current, a nie drzewa release czy stable,
  1. Przetestuj problem przynajmniej dwukrotnie ze źródłami zaktualizowanymi w kilkudniowym odstępie czasu od siebie.
  2. Nie zgłaszaj problemów z kompilacją drzewa źródeł, chyba że notorycznie się powtarzają. Są one prawie zawsze błędem po stronie użytkownika lub są już rozwiązywane w czasie, gdy na nie napotykasz. Osoby zaangażowane w projekt wykonują make build przynajmniej raz dziennie, a zwykle kilka razy dziennie na różnych architekturach.
  3. Pamiętaj, że serwery anoncvs są aktualizowane ze znacznym opóźnieniem w stosunku do aktualnie opracowywanego drzewa źródeł.
  4. Sprawdzaj zmiany pomiędzy wersjami OpenBSD aby sprawdzić czy przypadkiem problem nie został już rozwiązany.
  5. Dużo uwagi poświęcone jest tworzeniu snapshot'ów. Czasem popełniane są błędy, za co bardzo przepraszamy. Czytanie/pisanie na listy mailingowe w tej materii jest bardziej odpowiednie niż przesyłanie raportu o błędach.

Jak stworzyć raport o błędach

Zawsze dostarczaj tak dużo informacji jak jest to możliwe. Spróbuj wskazać konkretny problem. Nigdy nie udzielaj mało konkretnych opisów ani nie opisuj problemu na zasadzie "zawiesza się" lub "Mam dziwne zwisy na maszynce, którą zbudowałem". Rozmawiaj z innymi na IRC-u lub na innych forach aby sprawdzić czy dany problem jest faktycznie nowo-odkryty i występuje także u innych, i że nie stanowi problemu lokalnego.

Nie zaczynaj rozwiązywać problemu, który wymaga sporej pracy, dopóki nie jesteś pewien ze wszystko dokładnie rozumiesz - szczególnie w okresach wydawniczych, kiedy to nie możemy sobie pozwolić na poważne zmiany w kodzie. Jeżeli zamierzasz napisać dużą ilość kodu, sprawdź różne fora i upewnij się ze ktoś inny już nie pracuje nad tym problemem (oszczędzając sobie zdublowanej roboty).

Następujące rzeczy powinny być zawarte w każdym raporcie o błędach:

  1. Dokładną kolejność kroków zaczynając od początku aby odtworzyć dany problem. Opis i dane do niego dostarczone powinny być w całości wystarczające aby odtworzyć problem. Nie wystarczy przysłać samą komendę bez argumentów oraz danych, na których operacja była wykonywana. Jeżeli dany błąd wymaga konkretnej sekwencji zdarzeń, proszę je wyszczególnić. Zachęcamy do minimalizowania objętości dokumentacji dotyczącej danego problemu/błędu, jednakże nie jest to absolutnie konieczne. Jeżeli błąd można odtworzyć - my i tak znajdziemy na to sposób.

  2. Wynik operacji, przy której wystąpił problem. Nie pisz ze "to nie wyszło". Jeżeli dostałeś komunikat o błędzie, pokaż ją, nawet jeżeli sam go nie rozumiesz. Jeżeli występuje kernel panic przy konkretnym błędzie, wskaż, przy którym. Jeżeli w ogóle nic się nie dzieje, zaznacz to również. Nawet jeżeli rezultatem Twojego testu jest zawieszenie się programu, może się zdarzyć ze u nas tak się akurat nie zdarzy. Najprościej skopiować efekt końcowy z terminala, jeżeli jest to możliwe.

    Uwaga: W wypadku poważnych błędów, komunikat o błędzie może nie zawierać wszystkich dostępnych informacji. W takich wypadkach sprawdź również informacje dostępne z plików logów systemowych, na przykład tych z /var/log. Jeżeli korzystasz z aplikacji, która posiada swój własny system logów, jak na przykład httpd, sprawdź również te logi (dla przykładu httpd trzyma logi w /var/www/logs).

  3. OpenBSD kernel output. Możesz to otrzymać za pomocą komendy dmesg, ale możliwym jest, że to co otrzymasz po użyciu tej komendy nie będzie zawierało wszystkich informacji, które są przechwytywane do /var/run/dmesg.boot. W takim przypadku dołącz informację z obu źródeł. Umieszczaj ten rodzaj informacji we wszystkich raportach.

  4. Jeżeli używasz innego oprogramowania, które może mieć związek z danym problemem, zaznacz to, podając jakiekolwiek niekorzystne skutki działania tego oprogramowania. Jeżeli posiadasz jakiś CVS lub FTP snapshot wspomnij o tym i podaj ich datę i czas.

  5. Informacje śledzące (traceback) z twojego błędu jądra (kernel panic). Jeśli wystąpił błąd "kernel panic" w twoim jądrze, i zostałeś przeniesiony do ddb> , proszę dostarcz informacje o tym błędzie, wraz z informacjami z komend trace i ps załączonymi w twoim zgłoszeniu błędu, zgodnie z zaleceniami.
    Jeśli z jakiegoś względu informacja błędu (the panic message) nie jest widoczna, możesz ją odzyskać przy pomocy komendy show panic.
    Jest to niezwykle przydatne. Raporty o błędach jądra (panic reports) bez zawartości błędu (panic message), informacji śledzących (traceback) i ps są bezużyteczne.
    Wynik show registers także może być przedmiotem zainteresowania. Możesz także ponownie uruchomić system z boot dump aby obraz jądra mógł być zapisany przez savecore(8) do dalszego pośmiertnego debugging-u.

  6. Jeżeli zgłaszasz problem z systemem X window (X Window System) wykorzystującym architekturę X.Org, dołącz do raportu kompletny plik /var/log/Xorg.0.log w miejscu gdzie zawarłeś informacje z dmesg.boot.

Nie obawiaj się, że twoje raporty staną się zbyt długie. Jest faktem, że lepiej raportować wszystko za jednym razem, niż abyśmy my wyciągali informacje od Ciebie. Z drugiej strony, jeżeli Twoje pliki są duże, warto spytać wcześniej czy ktoś jest zainteresowany wglądem do nich.

Na koniec. Pisząc raport, staraj się nie używać skomplikowanej terminologii.

Wysyłanie raportów o błędach

Jeśli jest to możliwe, użyj polecenia sendbug(1) żeby zgłosić błąd do naszego system monitoringu. Możesz obserwować błąd na tej stronie Sendbug wymaga żeby twój system właściwie przesyłał e-maile. Jeśli nie możesz używać sendbug na funkcjonalnej maszynie OpenBSD, prześlij raport o błędzie na adres bugs@openbsd.org.

Być może to, co wysyłasz jest przyszłym zadaniem, nie koniecznie błędem. Nowe pomysły są chętnie przyjmowane, najlepiej z kodem źródłowym, który potwierdza twoja sugerowana zmianie(dodatek). Jeśli ktoś jeszcze pisze kod dla twojego nowego dodatku, istnieją szansę, że będzie źle zrozumiany i utworzony w sposób taki ze go nie rozpoznasz.

Dla usuwania niektórych błędów, musimy mieć sprzęt komputerowy, na którym ten błąd się pojawiał. Proszę pamiętać, że zasoby projektu OpenBSD są ograniczane. Kliknij tutaj aby podarować nam jakiś sprzęt.

Typy raportów o błędach w kolejności pojawiania:

  1. Powtarzające się błędy z naprawa źródła są najlepsze.
  2. Powtarzające się błędy, które nie są zdefiniowane dla twojego komputera/oprogramowania.
  3. Powtarzające się błędy dla swojego oprogramowania.
  4. Powtarzające się błędy dla twojego komputera.
  5. Niepowtarzające się błędy -- lub błędy, które nie chcesz by się powtórzyły.

OpenBSD www@openbsd.org
$OpenBSD$