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
