Dziękujemy za zainteresowanie projektem śledzenia błędów Ubuntu .
Od wersji 12.04 to zachowanie i przepływ pracy uległy zmianie. Jak odkryłem w Bug # 993450 „Apport nie wysyła raportu o błędzie”, domyślnie apport nie otwiera już raportu o błędzie (i jest to niewygodne, ale nie niemożliwe).
Apport nigdy nie tworzył raportów o błędach po wydaniu. Gdy wydanie jest wciąż w fazie rozwoju, możesz użyć apport, aby zapisać błędy Launchpad (i raporty błędów).
W ostatecznej wersji Ubuntu wyświetlamy teraz okna dialogowe błędów. Jest to doskonała poprawa, ponieważ program „odchodzi” bez żadnej informacji zwrotnej, a użytkownik zastanawia się, co się właśnie stało.
Statystyki z danych zebranych, gdy ludzie zdecydują się wysłać te raporty, pojawiają się na stronie http://errors.ubuntu.com .
Pozostaje mi pytanie: w jaki sposób użytkownik dowiaduje się, jaki jest status problemu? Plan ma teraz ten wymóg
Użytkownik powinien mieć możliwość sprawdzenia statusu swojego raportu o awarii; np. mieć identyfikator raportu, na który mogą spojrzeć, aby zobaczyć statystyki i / lub powiązany błąd #. Na przykład podaj numer seryjny w momencie składania, który można później załadować za pośrednictwem strony internetowej.
Zamierzam to usunąć. To nigdy nie było celem. Interfejs użytkownika stara się nie składać obietnic dotyczących uzyskiwania informacji zwrotnych na temat raportu.
To nie są zgłoszenia błędów.
Naszym celem jest skrócenie czasu potrzebnego programistom na znalezienie najbardziej palących problemów, zebranie potrzebnych informacji w celu ich rozwiązania i dostarczenie poprawek użytkownikom.
Rozwiązaliśmy problem znajdowania najbardziej palących problemów. To jest strona główna http://errors.ubuntu.com .
Szybkie zbieranie potrzebnych informacji i bez angażowania długiej pętli informacji zwrotnych z użytkownikami, którzy doświadczają problemu, zostało rozwiązane w udoskonaleniach programu fundations-q-bucketing . Plan ma umożliwić programistom podłączenie się do procesu gromadzenia informacji po stronie serwera. Jeśli potrzebuję / var / log / syslog, ale nie zostało to jeszcze dostarczone, po prostu zmieniam ustawienie na http://errors.ubuntu.com, a następna osoba, która napotka błąd, automatycznie dodaje to do wysyłanych danych.
Szybkie uzyskiwanie poprawek dla użytkowników jest omawiane w raportach fundations-q-updates-from-crash . Gdy użytkownicy prześlą raport o błędzie, a błąd ten został już naprawiony i wydany, pojawi się okno dialogowe z pytaniem, czy chcieliby zaktualizować oprogramowanie do wersji, która naprawia właśnie napotkany problem.
W jaki sposób deweloper wchodzi do gry? Wchodząc na https://daisy.ubuntu.com, pojawia się tylko komunikat o błędzie „Nieprawidłowy typ zawartości”.
http://daisy.ubuntu.com nie jest przeznaczony do użytku przez ludzi. Jest tam demon raportujący błędy (whoopsie), który wysyła raporty.
Byłoby absolutnie cudowne, gdyby inni ludzie się w to zaangażowali. Obecnie jestem jedynym hakerem w tym pełnym wymiarze godzin.
System składa się z czterech części.
- Apport , który zapewnia interfejs użytkownika pulpitu.
- Whoopsie , który pobiera raporty (i zrzuty pamięci) utworzone przez Apport i umieszcza je na serwerze śledzenia błędów, Daisy.
- Daisy , która zbiera raporty od Whoopsie i przetwarza je. To jest sedno usługi. To właśnie zamienia podstawowe pliki w śledzone raporty i generuje statystyki widoczne na stronie http://errors.ubuntu.com .
- Błędy , czyli strona internetowa oparta na Django, zapewniająca zarówno czytelny widok danych, jak i interfejs API RESTful do pracy z nimi.
W katalogu lp: daisy znajduje się nieco nieaktualny zestaw skryptów w katalogu setup /, który powinien dać ci pojęcie o tym, jak te elementy pasują do siebie. Pracowałem nad urokami juju, aby to zastąpić. Celem jest pojedyncze polecenie wdrożenia całej infrastruktury w chmurze w celu testowania i rozwoju.
Możesz znaleźć mój adres e-mail na Launchpad, jeśli masz dalsze pytania dotyczące programowania.
Więcej informacji: