Uwaga: Oryginał jest nowszy niż to tłumaczenie.

Wprowadzenie do pocztowego serwera kontroli i manipulacji błedów

Tak jak [email protected] pozwala pobierać dane i dokumentację o błędach przy użyciu poczty elektronicznej, tak [email protected] pozwala w różny sposób operować na zgłoszeniach błędów.

Serwer kontroli pracuje podobnie do serwera żądań z tą różnicą, że posiada kilka dodatkowych poleceń; tak naprawdę to jest to ten sam program. Te dwa adresy są rozdzielone jedynie po to, aby zapobiec błędom popełnianym przez użytkowników, które mogą powodować problemy, podczas gdy celem było jedynie żądanie informacji.

Jako, że polecenia serwera kontroli zmieniają status błędu, opiekun pakietu otrzymuje informację o przetworzeniu poleceń. Dodatkowo wiadomość przesłana do serwera oraz wywołane przez nią zmiany są zapisywane w zgłoszeniu błędu, tym samym są dostępne poprzez strony WWW.

Szczegółowe informacje na temat podstaw obsługi serwera i wspólne polecenia dla obu adresów można znaleźć pod adresem wprowadzenie do serwera żądań dostępnym na stronach WWW, w pliku bug-log-mailserver.txt lub pobrać je wysyłając polecenie help na adres któregokolwiek serwera.

Spis poleceń dla serwerów pocztowych dostępny jest na stronach WWW, w pliku bug-mailserver-refcard.txt lub do pobrania wysyłając wiadomość z poleceniem refcard.

Polecenia dostępne dla pocztowego serwera kontroli

Podstawowe	Wersjonowanie	Duplikaty	Różne
reassign severity tags retitle submitter affects summary outlook	found \| notfound fixed \| notfixed reopen	merge \| unmerge forcemerge clone	thanks # forwarded \| notforwarded owner \| noowner block \| unblock archive \| unarchive user \| usertag \| usercategory

reassign numer_błędu pakiet [ wersja ]

Zapisuje informację, że błąd #numer_błędu dotyczy podanego pakietu. Przy pomocy tego polecenia można określić pakiet, jeżeli użytkownik zapomniał zrobić to przy pomocy pseudo-nagłówka lub zmienić wcześniejsze przypisanie. Nie są wysyłane żadne zawiadomienia (oprócz zwykłej informacji o przetworzeniu polecenia).

Jeżeli będzie podana wersja pakietu, system kontroli błędów odnotuje, że błąd dotyczy tej wersji nowo przypisanego pakietu.

Można przypisać błąd do dwóch pakietów jednocześnie poprzez oddzielenie nazw przecinkiem. Jednakże należy to robić tylko, jeżeli błąd może być naprawiony przez zmianę jednego z wymienionych pakietów. W innym przypadku należy skopiować błąd i przypisać go do drugiego pakietu.

reopen numer_błędu [ adres-twórcy | = | ! ]

Ponownie otwiera błąd #numer_błędu i usuwa wszystkie poprawione wersje jeśli jest on zamknięty.

Domyślnie, lub jeżeli poda się znak =, osoba pierwotnie zgłaszająca błąd wciąż pozostaje twórcą raportu, więc otrzyma ona potwierdzenie w momencie ponownego zamknięcia błędu.

Jeżeli poda się adres-twórcy, twórca zostanie zmieniony na podany adres. Aby zostać twórcą ponownie otwieranego zgłoszenia, należy użyć skrótu ! lub podać własny adres pocztowy.

Zwykle dobrym pomysłem jest powiadomienie osoby, która zostanie zapisana jako twórca zgłoszenia, że otwiera się ponownie dany raport o błędzie aby wiedziała by oczekwiać potwierdzenia, które otrzyma kiedy błąd zostanie ponownie zamknięty.

Jeśli błąd nie jest zamknięty, wtedy polecenie ponownego otwarcia nie da żadnego efektu, nie zmieni nawet twórcy zgłoszenia. Aby zmienić twórcę otwartego zgłoszenia należy użyć polecenia submitter; należy zauważyć, że to polecenie powiadomi o zmianie pierwotnego autora.

Jeżeli błąd został zarejestrowany jako zamknięty w konkretnej wersji pakietu ale powtórzył się ponownie w późniejszej, zaleca się użycie polecenia found.

found numer_błędu [ wersja ]

Zapisuje informację, że błąd #numer_błędu znaleziono w podanej wersji pakietu do którego został przypisany. Wersja może być podana w pełnej postaci wg schematu nazwa_pakietu/wersja.

System kontroli błedów używa tych informacji, w połączeniu z poprawioną wersją zarejestrowaną podczas zamykania błędu, by wyświetlić listę błędów otwartych w różnych wersjach pakietu. Uzna, że błąd powinien być otwarty, kiedy nie ma poprawionej wersji lub jeśli błąd został znaleziony później, niż został poprawiony.

Jeżeli nie podano wersji, wtedy lista wersji z poprawionym błędem jest czyszczona. Jest to działanie identyczne do polecenia reopen. Wersja może być podana w pełnej postaci wg schematu nazwa_pakietu/wersja.

To polecenie działa tylko w odniesieniu do błędów oznaczonych jako niepoprawione (ang. not done) jeżeli nie podano wersji, lub, jeżeli podano wersję, do znalezionych błędów w wersji równej lub większej niż najwyższa wersja oznaczona jako poprawiona. (Aby oznaczyć błąd jako niepoprawiony (ang. not done) należy użyć polecenia reopen w połączeniu z poleceniem found.)

Komenda została wprowadzona aby zastąpić polecenie reopen, ponieważ dodanie wersji do składni tego polecenia bez wprowadzania niejasności byłoby trudnym zadaniem.

notfound numer_błędu wersja

Usuwa zapis o tym, że #numer_błędu został zarejestrowany w podanej wersji pakietu, do którego został dołączony. Wersja może być podana w pełnej postaci wg schematu nazwa_pakietu/wersja.

Różni się to od zamykania błędu w podanej wersji tym, że błąd nie znajdzie się również na liście błędów poprawionych; nie będzie żadnej informacji dotyczącej tej wersji. Polecenie jest przeznaczone do poprawiania błędnych zapisów dotyczących informacji o tym, kiedy dany błąd został zgłoszony.

fixed numer_błędu wersja

Wskazuje, że błąd #numer_błędu został poprawiony w podanej wersji pakietu, do którego został przypisany. Wersja może być podana w pełnej postaci wg schematu nazwa_pakietu/wersja.

Nie powoduje to oznaczenia błędu jako zamknięty, jedynie dopisuje kolejną wersję, w której błąd został poprawiony. Aby zamknąć błąd i oznaczyć go jako poprawiony w podanej wersji, należy użyć adresu pocztowego numer_błędu-done.

notfixed numer_błędu wersja

Usuwa zapis, że błąd #numer_błędu został poprawiony w podanej wersji. Wersja może być podana w pełnej postaci wg schematu nazwa_pakietu/wersja.

Polecenie jest równoważne poleceniu found, po którym wydano polecenie notfound (found usuwa poprawki w podanej wersji, a notfound usuwa wyniki polecenia found) z tą różnicą, że zgłoszenie nie jest otwierane ponownie, jeżeli znaleziona wersja jest większa niż jakakolwiek istniejąca poprawiona wersja. Polecenie jest przeznaczone do poprawiania pomyłek w zapisach, kiedy błąd został naprawiony; w większości przypadków należy używać polecenia found, a nie notfixed.

submitter numer_błędu adres-twórcy | !

Zmienia twórcę zgłoszenia #numer_błędu na adres-twórcy.

Aby zostać nowym twórcą raportu należy użyć skrótu ! lub podać własny adres pocztowy.

Podczas gdy polecenie reopen zmienia twórcę innych błędów powiązanych z błędem ponownie otwieranym, submitter nie ma wpływu na powiązane błędy.

forwarded numer_błędu adres

Zawiadamia, że błąd numer_błędu został przesłany do autora kodu źródłowego (upstream maintainer) na podany adres. To polecenie tak naprawdę nie wysyła dalej zgłoszenia. Może być ono użyte do zmiany istniejącego, nieprawidłowego adresu forwarded-to, lub do zapisania nowego adresu w zgłoszeniu, które wcześniej nie było oznaczone jako przesłane dalej. Adres powinien być w postaci URI lub poprawnego adresu pocztowego. Użycie URI, jeżeli jest to możliwe, pozwala na odpytywanie zdalnego systemu śledzenia błędów (np. bugzilla) aby pobrać status danego błędu.

Przykład użycia:

      forwarded 12345 http://bugz.illa.foo/cgi/54321

notforwarded numer_błędu

Usuwa informację, że numer_błędu był wysyłany dalej do jakiegokolwiek autora kodu źródłowego (upstream maintainer). Jeżeli błąd nie był zaznaczony jako wysłany dalej, to polecenie nie robi nic.

retitle numer_błędu nowy_tytuł

Zmienia tytuł zawiadomienia na podany w poleceniu (domyślnie pobierane jest pole Subject z nagłówka wiadomości oryginalnego zgłoszenia). Zmieniane są także tytuły we wszystkich zgłoszeniach powiązanych ze zgłoszeniem o podanym numerze.

severity numer_błędu stopień_ważności

Ustawia stopień ważności (severity) dla zgłoszenia #numer_błędu na podany stopień. Nie jest wysyłane powiadomienie do użytkownika zgłaszającego błąd.

Stopnie ważności to critical, grave, serious, important, normal, minor, wishlist.

Opis co oznaczają poszczególne stopnie znajduje się w podstawowej dokumentacji dla deweloperów dotyczącej systemu śledzenia błędów.

affects numer_błędu [ + | - | = ] pakiet [ pakiet ... ]

Oznacza, że błąd ma wpływ na inny pakiet. W przypadku, gdy numer_błędu powoduje problemy w pakiecie niezależnie od tego, czy błąd rzeczywiście występuje w podanym pakiecie, polecenie powoduje wyświetlenie błędu na listach dotyczących podanych pakietów. Polecenie powinno być używane jeżeli błąd jest na tyle poważny, by być powodem wielu zgłoszeń od użytkowników, którzy przypiszą go do złego pakietu. Znak = określa, że błąd wpływa na podaną listę pakietów i jest domyślną akcją jeżeli nie podano pakietów; znak - usuwa podane pakiety z listy pakietów, na które ma wpływ dany błąd; znak + dodaje podane pakiety do listy pakietów i jest domyślną akcją jeżeli podano pakiety.

summary numer_błędu [numer_wiadomości | podsumowanie]

Wybiera wiadomość, która będzie użyta jako podsumowanie błędu. Pierwszy akapit wiadomości, który nie jest pseudo-nagłówkiem i sekcją kontrolną jest przetwarzany i ustawiany jako podsumowanie błędu wyświetlane na początku strony zgłoszenia błędu. Polecenie może być użyte w sytuacji, kiedy pierwsze zgłoszenie nie opisuje dokładnie problemu lub błąd posiada wiele wiadomości, co utrudnia zidentyfikowanie sedna sprawy.

Jeżeli nie podano numeru wiadomości, podsumowanie jest czyszczone. Numer wiadomości jest numerem wyświetlanym w rapocie o błędzie generowanym przez skrypt cgi; jeżeli poda się wartość 0, zostanie użyta obecna wiadomość (czyli wiadomość wysłana na adres [email protected] zawierająca polecenie summary).

Jeżeli numer wiadomości nie jest liczbą i nie jest pustym tekstem, przyjmuje się że jest to tekst, który należy ustawić jako podsumowanie.

outlook numer_błędu [numer_wiadomości | tekst]

Wybiera wiadomość która będzie użyta jako opis możliwego sposobu naprawienia błędu (lub jako opis obecnego stanu prac nad poprawieniem błędu). Pierwszy akapit wiadomości, który nie jest pseudo-nagłówkiem i sekcją kontrolną jest przetwarzany i ustawiany jako opis sposobu naprawienia błędu wyświetlany na początku strony zgłoszenia błędu. Polecenie jest używane do koordynowania prac z innymi osobami nad poprawieniem danego błędu (np. podczas bug squashing party).

Jeżeli nie podano numeru wiadomości opis jest czyszczony. Numer wiadomości jest numerem wyświetlanym w rapocie o błędzie generowanym przez skrypt cgi; jeżeli poda się wartość 0, zostanie użyta obecna wiadomość (czyli wiadomość wysłana na adres [email protected] zawierająca polecenie outlook).

Jeżeli numer wiadomości nie jest liczbą i nie jest pustym tekstem, przyjmuje się że jest to tekst, który będzie ustawiony jako opis sposobu naprawy błędu.

clone numer_błędu nowy_numer_ID [ nowe_numery_ID ... ]

Polecenie clone pozwala na zduplikowanie raportu o błędzie. Przydaje się w przypadku, gdy pojedyńcze zawiadomienie wskazuje na pojawienie się wielu różnych błędów. Nowe numery ID to liczby ujemne, oddzielone spacjami, które mogą być użyte w kolejnych poleceniach, w celu odniesienia się do nowo stworzonych zgłoszeń. Dla każdego numeru ID tworzone jest nowe zgłoszenie o błędzie.

Przykład użycia:

          clone 12345 -1 -2
          reassign -1 foo
          retitle -1 foo: foo sucks
          reassign -2 bar
          retitle -2 bar: bar sucks when used with foo
          severity -2 wishlist
          clone 123456 -3
          reassign -3 foo
          retitle -3 foo: foo sucks
          merge -1 -3

merge numer_błędu numer_błędu ...

Łączy dwa lub więcej zgłoszeń o błędach. Jeśli zgłoszenia są złączone, wtedy otwarcie, zamknięcie, zaznaczenie lub odznaczenie jako przesłane dalej, ponowne przypisanie któregokolwiek z błędów do nowego pakietu będzie miało identyczny efekt dla każdego ze złączonych zgłoszeń.

Przed złączeniem błędy muszą być w takim samym stanie, to znaczy: albo wszystkie są otwarte albo zamknięte, z tym samym adresem autora kodu źródłowego, do którego przesyłane są błędy, albo wszystkie nie są oznaczone jako przesyłane dalej, wszystkie muszą być przydzielone do tego samego pakietu lub pakietów (dokonywane jest dokładne porównanie łańcuchów znaków w nazwie pakietu, do którego błąd jest przydzielony) i wszystkie muszą mieć ten sam stopień ważności. Jeśli błędy nie są w tym samym stanie wtedy należy użyć poleceń reassing, reopen itd., aby mieć pewność, że wszystkie zgłoszenia mają ustawiony taki sam stan przed użyciem polecenia merge. Tytuły zgłoszeń nie muszą być takie same, ponieważ nie są uwzględnianie podczas łączenia. Znaczniki również nie muszą być takie same - zostaną one połączone.

Jeśli którykolwiek z błędów wymienionych w poleceniu merge jest już połączony z innym błędem, wtedy wszystkie zgłoszenia połączone z którymkolwiek z nich będą także połączone. Funkcja łączenia jest jak znak równości: zwrotna, przechodnia i symetryczna.

Łączenie zgłoszeń powoduje wstawienie informacji w dzienniku (log) każdego zgłoszenia. Na stronach WWW oznacza to także odnośniki do innych błędów.

Połączone zgłoszenia przedawniają się razem, a dzieje się tak tylko wtedy, gdy wszystkie z osobna spełniają kryteria przedawnienia.

forcemerge numer_błędu numer_błędu ...

Wymusza łączenie dwóch lub więcej zgłoszeń o błędach. Ustawienia pierwszego podanego błędu, które muszą odpowiadać ustawieniom innych zgłoszeń przy normalnym połączeniu, są przepisywane do błędów wymienionych w następnej kolejności. Znaczniki są łączone jak przy merge. Aby zapobiec błędnym połączeniom zgłoszeń, muszą one dotyczyć tego samego pakietu. Opis, co umożliwia polecenie łączenia zgłoszeń znajduje się powyżej.

Należy zaznaczyć, że polecenie umożliwia poprzez połączenie zamknięcie zgłoszenia; użytkownik, który zamyka takie zgłoszenia, musi powiadomić osoby zgłaszające te błedy poprzez wysłanie odpowiedniej wiadomości.

unmerge numer_błędu

Rozłącza zgłoszenie o błędzie od innych zawiadomień, z którymi było złączone. Jeśli wypisane zawiadomienie jest złączone z kilkoma innymi, wtedy wszystkie są pozostawione jako złączone. Tylko bezpośrednie związki z tym błędem są usuwane.

Jeśli wiele zawiadomień o błędach jest złączonych i chcemy podzielić je na dwie oddzielne grupy, należy rozdzielić osobno każdy raport, który będzie przypisany do jednej z nowych grup, a następnie połączyć je w nową grupę.

Jednym poleceniem unmerge można rozdzielić tylko jedno zgłoszenie. Aby rozdzielić więcej niż jeden błąd, należy po prostu w wiadomości użyć kilku poleceń unmerge.

tags numer_błędu [ + | - | = ] tag [ tag ... ] [ + | - | = tag ... ] ]

Ustawia znaczniki (tags) dla zgłoszenia o błędzie #numer_błędu. Nie jest wysyłane żadne powiadomienie do osoby, która zgłosiła błąd. Ustawienie akcji na + oznacza dodanie wszystkich znaczników (tag) podanych po znaku, akcja - oznacza usunięcie wszystkich znaczników podanych po znaku, akcja = oznacza ustawienie znaczników na te podane po znaku. Operacja +, - i = zmienia akcję dla znaczników podanych po danej operacji. Domyślną akcją jest dodanie znacznika.

Przykłady użycia:

          # same as 'tags 123456 + patch'
          tags 123456 patch

          # same as 'tags 123456 + help security'
          tags 123456 help security

          # add 'fixed' and 'pending' tags
          tags 123456 + fixed pending

          # remove 'unreproducible' tag
          tags 123456 - unreproducible

          # set tags to exactly 'moreinfo' and 'unreproducible'
          tags 123456 = moreinfo unreproducible
	  
	  # remove the moreinfo tag and add a patch tag
	  tags 123456 - moreinfo + patch

Obecnie są obsługiwane następujące znaczniki patch, wontfix, moreinfo, unreproducible, help, security, upstream, pending, confirmed, ipv6, lfs, d-i, l10n, newcomer, a11y, ftbfs, fixed-upstream, fixed, fixed-in-experimental, potato, woody, sarge, etch, lenny, squeeze, wheezy, jessie, stretch, buster, bullseye, bookworm, trixie, forky, sid, experimental, sarge-ignore, etch-ignore, lenny-ignore, squeeze-ignore, wheezy-ignore, jessie-ignore, stretch-ignore, buster-ignore, bullseye-ignore, bookworm-ignore, trixie-ignore forky-ignore .

Opis znaczenia poszczególnych znaczników znajduje się w ogólnej dokumentacji dla deweloperów dotyczącej systemu śledzenia błędów.

block numer_błędu by błąd ...

Polecenie oznacza, że poprawka do pierwszego błędu jest blokowana przez podane błędy.

unblock numer_błędu by błąd ...

Polecenie oznacza, że poprawka do pierwszego błędu nie jest już blokowana przez podane błędy.

close numer_błędu [ wersja_poprawiona ] (przestarzałe)

Zamyka zgłoszenie o błędzie #numer_błędu.

Do osoby zgłaszającej błąd jest wysyłana informacja, ale (w odróżnieniu od wysłania wiadomości na adres numer_błędu[email protected]) treść wiadomości, która spowodowała zamknięcie błędu, nie jest dołączana do wysyłanej informacji. Opiekun, który zamyka zgłoszenie musi się upewnić, prawdopodobnie przez wysłanie osobnej wiadomości, że użytkownik zgłaszający dany błąd wie, dlaczego jest on zamykany. Z tego powodu używanie tego polecenia jest przestarzałe. Informacje, jak prawidłowo zamknąć błąd znajdują się w dokumentacji dla deweloperów.

Jeżeli będzie podany parametr wersja_poprawiona, system śledzenia błędów zapisze, że błąd poprawiono w podanej wersji pakietu.

package [ nazwa_pakietu ... ]

Ogranicza dalsze polecenia tak, aby działały wyłącznie na błędach dotyczących wymienionych pakietów. Można podać jeden lub więcej pakietów. Jeżeli nie poda się żadnego pakietu, dalsze polecenia będą dotyczyły wszystkich błędów. Zachęcamy do używania tego polecenia jako zabezpieczenia na wypadek, gdyby podano złe numery błędów.

Przykładowe użycie:

          package foo
          reassign 123456 bar 1.0-1

          package bar
          retitle 123456 bar: bar sucks
          severity 123456 normal

          package
          severity 234567 wishlist

owner numer_błędu adres | !

Ustawia adres jako właściciela błędu #numer_błędu. Właściciel przejmuje odpowiedzialność za naprawienie podanego błędu. Polecenie jest przydatne do dzielenia się pracą w przypadku, gdy pakietem zajmuje się grupa opiekunów.

Aby zostać właścicielem podanego błędu, można użyć skrótu ! lub podać własny adres email.

noowner numer_błędu

Usuwa wszelkie informacje, że podany błąd miał innych właścicieli oprócz opiekuna. Jeżeli zgłoszenia nie miało właściciela, polecenie nic nie zrobi.

archive numer_błędu

Archiwizuje błąd, który już kiedyś był zarchiwizowany (ale obecnie nie jest) jeżeli błąd spełnia wymagania potrzebne do archiwizacji, czas jest ignorowany.

unarchive numer_błędu

Usuwa znacznik archiwum dla błędu, który wcześniej został zarchiwizowany. Akcja powinna być połączona z odpowiednim poleceniem reopen i found/fixed. Błąd, który został odarchiwizowany może zostać zarchiwizowany zakładając, że spełniono podstawowe wymagania dotyczące archiwizacji (oprócz tych związanych z datą). Nie powinno się używać tej opcji do prostych zmian w zarchiwizowanych błędach, np. zmiany osoby zgłaszającej. Głównym celem polecenia jest umożliwienie ponownego otwarcia błędu, który został zarchiwizowany, bez interwencji ze strony administratorów BTS.

#...

Jednoliniowy komentarz. # musi znajdować się na początku linii. Treść komentarzy będzie dołączana w potwierdzeniu wysłanym do zgłaszającego oraz do odpowiednich opiekunów, więc można ich używać do wyjaśniania powodów dla wydanych poleceń.

quit

stop

thank

thanks

thankyou

thank you

--

W osobnej linii, w każdym przypadku, może być z następującymi po tych znakach białymi znakami, zatrzymuje przetwarzanie wiadomości przez serwer kontroli; pozostała część wiadomości może zawierać wyjaśnienie, podpis lub cokolwiek innego, żaden tekst nie będzie wykrywany przez serwer kontroli.

Inne strony WWW systemu śledzenia błędów:

Debian BTS administrators <[email protected]>