W jaki sposób błędy są dzielone na kategorie i jaki jest cykl życia błędu?

Jak kategoryzowane są błędy w Ubuntu i jaki jest cykl życia błędu?

Ponadto „Co oznacza„ Status ”każdego błędu i jak jest ustalany”

Wszystkie błędy w Ubuntu mają cykle życia. Każdy z nich ma również „Status”, który pomaga wyjaśnić jego cykl życia. W Ubuntu, każdy błąd w trakcie jego cyklu życia ma ustawione różne statusy.

Chociaż wszystko to jest szczegółowo opisane w Przewodniku Triage , będę (na razie, ponieważ nie mam dużo czasu na napisanie tego procesu w tekście, ale później) opublikuję „Schematy blokowe” dostarczone przez Zespół Bug w tym celu ( kliknij tutaj, aby zobaczyć źródło schematów blokowych ). Każdy status (w międzyczasie) można wyjaśnić w dokumentacji błędów / statusu BugSquad , ale tutaj też je udokumentowałem.

(Uwaga: poniższe informacje mogą być nieaktualne w dokumentacji na wiki, należy zapoznać się z wiki, aby uzyskać najbardziej aktualne informacje).

Poniżej znajduje się opis każdego wskaźnika statusu błędu:

• Nowy:
  • Błędy są zgłaszane z tym statusem
  • Czasem brakuje im informacji i
  • Wszystkie powinny być nieuporządkowane
• Niekompletny:
  • Jeśli musisz zadać dziennikarzowi pytania, ustaw błąd na Nieukończone
  • Poproś zgłaszającego o podanie wszelkich niezbędnych informacji w komentarzu i upewnij się, że zasubskrybowałeś raport o błędzie, aby otrzymywać aktualizacje e-mailem.
  • Na niektóre błędy autor nigdy nie odpowiada (zwany także „oryginalnym plakatem” lub „OP”). Błędy zostaną automatycznie wygasione przez Launchpad za 60 dni, licząc od dnia, w którym zostały ustawione jako niekompletne. Nie trzeba na nich działać (a zmiana błędu spowoduje ponowne uruchomienie okresu ważności). Zauważ, że dotyczy to projektu Ubuntu (tj. Zadań z błędami, które mają w nazwie „(Ubuntu)”). Inne projekty mogą, ale nie muszą, mieć ustawiony automatyczny niepełny okres ważności błędu.
  • Jeśli ktoś, w tym ty, skomentuje błąd, 60-dniowy zegar ważności zostanie zresetowany.
• Opinia:
  • Status „opinia” oznacza, że ​​istnieje rozbieżność opinii na temat konkretnego błędu i ludzie mogą swobodnie kontynuować dyskusję, ale opiekunowie projektu lub pakietu muszą przejść do innej pracy i rozważają rozwiązanie problemu. Chodzi o to, że błędy można oznaczyć jako zamknięte, więc programiści nie marnują na nie czasu, ale dyskusja może być nadal w toku.
  • Status „opinia” jest uważany za eksperyment i będzie ściśle monitorowany.
• Nieważny:
  • Ten status powinien być używany, gdy raport o błędzie nie zawiera odpowiednich informacji, aby ustalić, czy jest to błąd, nawet jeśli został rozwiązany dla zgłaszającego
  • Należy tego również użyć, jeśli zgłaszany problem nie jest błędem, ale na przykład błędem użytkownika
  • Należy go używać zachowawczo, ponieważ błędy oznaczone jako Nieprawidłowe nie pojawiają się już w domyślnych wyszukiwaniach
  • Pamiętaj, aby trzykrotnie sprawdzić błąd przed jego unieważnieniem
• Przedawniony:
  • Ten status jest podobny do Nieprawidłowy, ale jest przeznaczony specjalnie dla błędów, które były niekompletne zbyt długo. (Patrz wyżej.)
  • Ten status można ustawić tylko przy użyciu launchpadlib lub interfejsu e-mail.
  • Podobnie jak błędy nieprawidłowe, błędy, które wygasły, nie pojawiają się w wyszukiwaniu domyślnym.
• Potwierdzone :
  • Inny reporter doświadczył tego samego błędu, który może mieć postać duplikatu błędu lub komentarza błędu
  • Potwierdzone błędy wymagają potwierdzenia od kogoś innego niż oryginalny reporter
  • Pomaga to upewnić się, że błąd dotyczy ogólnie Ubuntu, a nie stanowi problemu z systemem reportera, dlatego ...
  • Nie potwierdzaj własnych błędów!
• Triaged:
  • Członek UbuntuBugControl uważa, że ​​raport opisuje prawdziwy błąd na tyle szczegółowo, aby deweloper mógł rozpocząć pracę nad poprawką. (patrz także wskazówka poniżej)
  • Użyj tego, jeśli masz pewność, że programista powinien na nie spojrzeć i ma wystarczająco dużo informacji
  • Chociaż nie jest to wymagane, status zadania Ubuntu dla błędu zostanie poddany Triaged, zanim nastąpi jakiekolwiek przekazywanie w górę
  • Z błędami dotyczącymi linuxa Triaged oznacza, że ​​błąd został przetestowany z głównym jądrem
• W trakcie:
  • Jeśli ty pracujesz na ustalenie błąd, ustawić go In Progress więc ludzie wiedzą, co się dzieje
  • Błędy w toku powinny być przypisane do osoby nad nimi pracującej
• Napraw zatwierdzone:
  • Zadanie błędu Ubuntu: zmiany są w toku i wkrótce zostaną przesłane (takie właśnie było PENDINGUPLOAD w Bugzilli)
  • Poprawka zatwierdzona jest używana również wtedy, gdy zaktualizowany pakiet istnieje w proponowanym repozytorium, tzn. Jest to wysoce zalecane
  • Poprawka zatwierdzona nie jest używana, gdy łatka jest dołączona do błędu
  • Zadanie błędu nadrzędnego: poprawka znajduje się w CVS / SVN / bzr lub jest przypisana do jakiegoś miejsca
• Poprawka wydana:
  • Zadanie błędu Ubuntu: poprawka została przesłana do oficjalnego repozytorium Ubuntu
  • Uwaga: Nie obejmuje to -zaproszenia, tj. Hardypropozycji
  • Nie wahaj się dodać dziennika zmian jako komentarza, aby ludzie wiedzieli, w której wersji pakietu naprawiono błąd
  • Jeśli błąd zostanie naprawiony w bieżącej wersji rozwojowej, zostanie on naprawiony. Jeśli błąd również wymaga naprawy w stabilnej wersji, użyj linku „Celuj do wydania”, aby wyznaczyć go do tej wersji.
  • Zadanie poprzedzające błąd: ogłoszono wydanie tarballa wydania i jest ono publicznie dostępne
• Nie naprawi się:
  • Ten status jest czasem używany, gdy poprawka jest zbyt kontrowersyjna
  • Jest najczęściej używany w przypadku błędów z celem wydania, który nie zostanie naprawiony w tym konkretnym wydaniu, ale może zostać naprawiony później
  • Może być również używany do żądań funkcji, których programiści nie chcą wdrożyć

(formatowanie będzie się nieco różnić od wiki, ponieważ formatowanie tutaj jest bardziej ograniczone)

Powiązane pytania i odpowiedzi:
Wartość ważności: W jaki sposób decyduje się o wartości ważności błędów Ubuntu