Uwaga: Oryginał jest nowszy niż to tłumaczenie.
Wprowadzenie do pocztowego serwera kontroli i manipulacji błedów
Tak jak request@bugs.debian.org
pozwala pobierać dane i dokumentację o błędach przy użyciu
poczty elektronicznej, tak control@bugs.debian.org
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
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 poleceniemfound
.)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 polecenienotfound
(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ć poleceniafound
, a nienotfixed
. 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 control@bugs.debian.org 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 control@bugs.debian.org 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 poleceniamerge
. 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łęduby
błąd ...- Polecenie oznacza, że poprawka do pierwszego błędu jest blokowana przez podane błędy.
unblock
numer_błęduby
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
-done@bugs.debian.org
) 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:
- Główna strona systemu śledzenia błędów.
- Jak zgłosić błąd.
- Dostęp do zgłoszonych błędów.
- Instrukcje użycia systemu dla rozwijających.
- Instrukcje dla rozwijających dotyczące manipulacji na zgłoszeniach przy pomocy poczty elektronicznej.
- Polecenia serwera pocztowego.
- Otrzymywanie zgłoszeń pocztą elektroniczną.
Debian BTS administrators <owner@bugs.debian.org>
Debian bug tracking system
Copyright © 1999 Darren O. Benham, 1997, 2003 nCipher Corporation Ltd,
1994-1997 Ian Jackson.