(Źródło: Błędy / Ważność (dokumentacja zespołu błędów) )
Skład błędów w Ubuntu jest jedną z sił napędowych błędów w Ubuntu i prowadzi dokumentację tego dla odniesienia każdej osoby.
Ze względu na osoby, które nie znoszą czytania innych stron, oraz dla kilku osób, które mogą być zbyt leniwe, aby kliknąć link na początku tej odpowiedzi, w zasadzie skopiuję dosłownie informacje z bazy wiedzy Bug Squad, które są istotne tutaj :
SZYBKA UWAGA : Gdy pojawia się odniesienie do „Core” lub „Non-Core”, zespół błędów traktuje „core” jako część pakietu ubuntu-desktop lub tego, co jest instalowane domyślnie na obrazach LiveCD. To może się zmienić w przyszłości, w zależności od dalszej dyskusji w Bug Squad na ten temat.
(Uwaga: poniższe informacje mogą być nieaktualne w dokumentacji na wiki, należy zapoznać się z wiki, aby uzyskać najbardziej aktualne informacje).
Ubuntu stosuje następujące wytyczne do przypisywania ważności. Znaczenie błędu oznacza priorytet, że powinien on zostać nadany przez osoby naprawiające błędy.
Oto znaczenie różnych wartości ważności):
- Niezdecydowany : domyślnie dla nowych błędów. Oznacza również, że nie ma wystarczających informacji, aby określić znaczenie
- Lista życzeń : brak funkcji
- Nie zawsze są to błędy, ale mogą to być pomysły na nowe funkcje, które jeszcze nie istnieją.
- Mogą to być również prośby o spakowanie oprogramowania dla Ubuntu.
- Jeśli implementacja nie jest trywialna, powinna raczej zostać zapisana jako specyfikacja funkcji, patrz Specyfikacje funkcji.
- Mogą to być błędy, które wpływają na eksperymentalne rozszerzenie lub nieistotną cechę danego pakietu / projektu.
- Błędy, które zostałyby naprawione tylko na zasadzie starania lub wkładu zewnętrznego, można również uznać za listę życzeń .
- Niski : Błędy wpływające na funkcjonalność, ale w mniejszym stopniu niż większość błędów, przykładami są:
- Błędy, które mają łatwe obejścia
- Błędy, które wpływają na nietypowe konfiguracje użytkownika końcowego lub nietypowy sprzęt
- Błędy, które wpływają na nieistotny aspekt i ograniczony zakres aplikacji
- Błędy, które mają umiarkowany wpływ na aplikacje inne niż podstawowe
- Problemy kosmetyczne / użyteczności, które nie ograniczają funkcjonalności aplikacji innej niż podstawowa
- Nieidealne konfiguracje domyślne
- Średni : większość błędów ma średnie znaczenie, przykłady to:
- Błąd, który ma umiarkowany wpływ na podstawową aplikację
- Błąd, który ma poważny wpływ na aplikację inną niż podstawowa
- Błąd, który wpływa na dostępność aplikacji innej niż podstawowa
- Problem z użytecznością, który nie ogranicza funkcjonalności podstawowej aplikacji
- Problem z nieistotnym komponentem sprzętowym (wymienna karta sieciowa, kamera, kamera internetowa, odtwarzacz muzyki, karta dźwiękowa, funkcja zarządzania energią, drukarka itp.)
- Wysoka : błąd, który spełnia jedno z następujących kryteriów:
- Ma poważny wpływ na niewielką część użytkowników Ubuntu (szacunkowo)
- Powoduje, że domyślna instalacja Ubuntu jest generalnie bezużyteczna dla niektórych użytkowników. (Na przykład, jeśli system nie uruchamia się lub X nie uruchamia się, na określonej marki i modelu komputera)
- Problem z istotnym składnikiem sprzętowym (kontroler dysku, wbudowana sieć, karta graficzna, klawiatura, mysz)
- Ma umiarkowany wpływ na dużą część użytkowników Ubuntu (szacunkowo)
- Zapobiega poprawnemu działaniu aplikacji lub jakichkolwiek zależności
- Renderuje podstawowe funkcje lub funkcje aplikacji lub zależności uszkodzone lub nieskuteczne
- Wpływa na dostępność podstawowej aplikacji
- Krytyczny : błąd, który ma poważny wpływ na dużą część użytkowników Ubuntu
- Powoduje uszkodzenie danych
- Awarie całego systemu operacyjnego
- Renderuje system tymczasowo lub na stałe nieużywalny
- Poważnie wpływa na aplikacje poza pakietem odpowiedzialnym za główną przyczynę
Członkowie Ubuntu Bug Control mają dostęp do ustawiania tych statusów ważności błędów pod nadzorem Ubuntu (w tym pakietów, które ubuntu-bugto zrobią) i mogą albo ustawić je sami, albo na prośbę członka Bug Squad, który nie jest członek kontroli błędów.
Zasadniczo, gdy zajmuję się błędami i decyduję o tym, czy jest on gotowy do segregowania (chyba że jest to rażąco oczywiste), postępuję zgodnie z Przewodnikiem triage, aby zdecydować, jak segregować błąd (który ustawia status błędu na „Triaged”) i wytyczne, które zamieściłem (i do których linkuję) powyżej w celu podjęcia decyzji o ważności. (Jestem w składzie Bug Bug i jestem członkiem Bug Control, jeśli jesteś ciekawy)
