#use wml::debian::template title="Debian BTS - serwer kontroli" NOHEADER=yes NOCOPYRIGHT=true
#use wml::debian::translation-check translation="1.49"

<h1>Wprowadzenie do serwera pocztowego kontroli i manipulacji błędów</h1>

<P>Jako uzupełnienienie do serwera pocztowego <code>request@bugs.debian.org</code>,
który pozwala na pobieranie danych i dokumentacji o błędach przy użyciu poczty
elektronicznej, istnieje inny serwer dostępny pod adresem
<code>control@bugs.debian.org</code>, który pozwala dodatkowo, w różny sposób,
operować na zgłoszeniach błędów.</P>

<P>Serwer kontroli pracuje podobnie do serwera żądań z wyjątkiem tego, że
posiada kilka dodatkowych poleceń. Tak naprawdę to jest to ten sam program.
Te dwa adresy są rozdzielone jedynie po to by zapobiec błędom popełnianym
przez użytkowników, które mogą stworzyć problemy podczas gdy celem było
jedynie żądanie informacji.</P>

<p>Jako, że polecenia serwera kontroli zmieniają status błędu, opiekun
pakietu otrzymuje informację o przetworzeniu poleceń. Dodatkowo wiadomość
przesłana do serwera oraz wynik poleceń jest zapisywany w zgłoszeniu błędu,
a przez to dostępny poprzez strony WWW.</p>

<P>Aby zapoznać się ze szczegółami obsługi serwerów pocztowych i wspólnymi
poleceniami dla obu adresów przeczytaj
<A href="server-request#introduction">wprowadzenie do serwera żądań</A>
dostępnego na stronach WWW, w pliku
<code>bug-log-mailserver.txt</code>, lub przez wysłanie polecenia
<code>help</code> na adres któregokolwiek serwera.</P>

<P><A href="server-refcard">Spis poleceń</A> dla serwerów pocztowych dostępny
jest na stronach WWW, w pliku
<code>bug-mailserver-refcard.txt</code> lub przez wysłanie polecenia 
<code>refcard</code>.</P>

<H1>Polecenia dostępne dla serwera pocztowego kontroli</H1>

<dl>

<dt><code>reassign</code> <var>numer_błędu</var> <var>pakiet</var>
 [ <var>wersja</var> ]
<dd>

Odnotowuje, że błąd nr <var>numer_błędu</var> jest błędem w pakiecie
<var>pakiet</var>. Polecenia tego można użyć aby ustalić pakiet, jeśli
użytkownik zapomniał o pseudo-nagłówku, lub do zmiany wcześniejszego
przydziału. Żadne zawiadomienie nie jest wysyłane do nikogo (oprócz zwykłej
informacji o przetworzeniu polecenia).

<p>Jeśli podasz <var>wersję</var>, system kontroli błędów odnotuje to,
że błąd wpływa na tę wersję nowo-przydzielonego pakietu.

<dt><code>reopen</code> <var>numer_błędu</var>
 [ <var>adres_źródła</var> | <code>=</code> | <code>!</code> ]
<dd>

Ponownie otwiera błąd nr <var>numer_błędu</var> jeśli jest on zamknięty.

<p>Domyślnie, lub jeśli podasz <code>=</code>, źródłem zgłoszenia
błędu pozostaje autor zawiadomienia więc otrzyma on potwierdzenie
w momencie ponownego zamknięcia błędu.</p>

<p>Jeśli podasz <var>adres_źródła</var> źródło zgłoszenia zostanie
ustawione na adres, który podałeś. Jeśli chcesz zostać nowym źródłem ponownie
otwartego zgłoszenia użyj skrótu <code>!</code> lub podaj własny adres
poczty elektronicznej.</p>

<p>Zwykle dobrym pomysłem jest aby zawiadomić osobę, która zostanie zapisana
jako źródło zgłoszenia że ponownie otwierasz raport o błędzie aby
wiedziała by oczekwiać potwierdzenia, które otrzyma kiedy błąd zostanie
ponownie zamknięty.</p>

<p>Jeśli błąd nie jest zamknięty wtedy polecenie ponownego otwarcia nie da
żadnego efektu, nie
zmieni nawet źródła zgłoszenia. Aby zmienić źródło otwartego zawiadomienia
użyj polecenia <code>submitter</code>. Zauważ, że to polecenie
zawiadomi oryginalnego autora zgłoszenia o zmianie.

<p>Jeżeli błąd został zarejestrowany jako zamknięty w konkretnej wersji
pakietu lecz powtórzył się w następnej wersji,
lepiej jest użyć komendy <code>found</code>.

<dt><code>found</code> <var>numer_błędu</var> [ <var>wersja</var> ]

<dt>Zauważ, że #<var>numer_błędu</var> został zauważony w podanej
<var>wersji</var> pakietu do którego został przydzielony.

<p>System kontroli wersji używa informacji, w połączeniu
z załataną wersją zarejestrowaną podczas zamykania błędu, by wyświetlić
listę błędów otwartych w różnych wersjach pakietów. Rozważa otwarcie błędu,
jeżeli nie posiada załatanej wersji, lub jeśli został znaleziony wcześniej,
niż kiedy został załatany.

<p>Jeśli <var>wersja</var> nie zostałą podana, wtedy lista załatanych wersji
błedu jest czyszczona. Jest to identyczne z zachowaniem
komendy <code>reopen</code>.

<p>Komenda ta została wprowadzona z powodu polecenia <code>reopen</code>,
ponieważ trudnym było dodanie <var>wersji</var> do składni
komendy bez wprowadzania niejasności.

<dt><code>notfound</code> <var>numer_błędu</var> <var>wersja</var>

<dd>Usuwa zapis o tym, że #<var>numer_błędu</var> został zarejestrowny
w podanej <var>wersji</var> pakietu, do którego został dołączony.

<p>Różni się to od zamykania błędu w tej wersji tym, że błąd nie znajduje
się na liście w tej wersji jako załatany; żadna informacja o tej wersji
będzie znana. Przeznaczone jest to do naprawiania pomyłek w zapisie tego,
kiedy błąd został znaleziony.

<dt><code>submitter</code> <var>numer_błędu</var>
<var>adres_źródła</var> | <code>!</code>
<dd>

Zmienia oryginalne źródło zawiadomienia o błędzie <var>numer_błędu</var> na
<var>adres_źródła</var>.

<p>Jeśli chcesz zostać nowym źródłem zgłoszenia możesz użyć skrótu
<code>!</code> lub podać własny adres poczty elektronicznej.</p>

<p>Podczas gdy polecenie <code>reopen</code> zmienia źródło innych zawiadomień
złączonych (merged) z tym, które jest ponownie otwierane, polecenie
<code>submitter</code> nie dotyczy złączonych błędów.</p>

<dt><code>forwarded</code> <var>numer_błędu</var> <var>adres</var>
<dd>

Zawiadamia, że błąd nr <var>numer_błędu</var> został przesłany do zewnętrznego
autora (upstream maintainer) na adres <var>adres</var>. To polecenie tak naprawdę 
nie wysyła dalej zawiadomienia. Polecenie może być używane do zmiany
istniejącego - nieprawidłowego adresu, na który przesyłany jest raport lub do
zapisania nowego adresu dla zgłoszenia, który nie był poprzednio zaznaczony jako
przesłany dalej.

<dt><code>notforwarded</code> <var>numer_błędu</var>
<dd>

Zapomina, że <var>numer_błędu</var> był wysyłany dalej do jakiegokolwiek
zewnętrznego autora (upstream maintainer). Jeśli błąd nie był zaznaczony jako
wysłany dalej to polecenie nie robi nic.

<dt><code>retitle</code> <var>numer_błędu</var> <var>nowy_tytuł</var>
<dd>

Zmienia tytuł zawiadomienia o błędzie na <var>nowy_tytuł</var> (domyślnie
tytułem błędu jest pole <code>Subject</code> z nagłówka wiadomości
oryginalnego zgłoszenia).

<p>Inaczej niż większość poleceń operujących na błędach, użyte na jednym
zestawie złączonych błędów zmieni tytuł tylko jednego z nich, podanego w
poleceniu, a nie wszystkich które zostały złączone.

<dt><code>severity</code> <var>numer_błędu</var> <var>stopień_ważności</var>
<dd>

<p>Ustawia stopień ważności (severity) dla zawiadomienia o błędzie nr
<var>numer_błędu</var> na <var>stopień_ważności</var>. Żadna informacja nie
jest wysyłana do użytkownika, który złożył zawiadomienie o błędzie. </p>

<p>Stopnie ważności to <code>critical</code>, <code>grave</code>,
<code>serious</code>, <code>important</code>, <code>normal</code>,
<code>minor</code> oraz <code>wishlist</code>.

<p>Aby dowiedzieć się co <A href="Developer#severities">oznaczają</A> zapoznaj
się z ogólną dokumentacją dla rozwijających o systemie śledzenia błędów.

<dt><code>clone</code> <var>numer_błędu</var> [ <var></var> ]

  <dd>Polecenie klonowania pozwala na powielenie zawiadomienia o
  błędzie. Jest ono użyteczne w przypadku gdy pojedyncze zawiadomienie
  wskazuje na pojawienie się wielokrotnych różnych od siebie błędów.
  ,,<var>nowe_numery_ID</var>'' to liczby ujemne, oddzielone spacjami, które
  mogą być użyte, w celu odniesienia się do nowo stworzonych zgłoszeń, w
  następnych poleceniach. Dla każdego numeru ID tworzone jest nowe zgłoszenie
  o błędzie.

  <p>Przykładowe użycie:</p>

  <pre>
        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
  </pre>

<dt><code>merge</code> <var>numer_błędu</var> <var>numer_błędu</var> ...
<dd>

Łączy dwa lub więcej zawiadomień o błędach. Jeśli zgłoszenia są złączone
wtedy otwieranie, zamykanie, zaznaczanie lub odznaczanie jako przesłane dalej
i dowiązywanie któregokolwiek z błędów do nowego pakietu będzie miało
identyczny efekt dla każdego ze złączonych zgłoszeń.

<p>Przed złączeniem błędy muszą być w takim samym stanie, to znaczy: albo
wszystkie są otwarte albo zamknięte, z tym samym adresem zewnętrznego autora,
do którego przesyłane są błędy albo nie są zaznaczone 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 powinieneś użyć poleceń
<code>reassign</code>, <code>reopen</code> itd. aby mieć pewność, że możesz
użyć polecenia <code>merge</code>. Tytuły zgłoszonych błędow nie muszą być
takie same, ponieważ nie są uzwględniane podczas łączenia. Znaczniki również
nie muszą być takie same - zostaną one połączone.</p>

<P>Jeśli którykolwiek z błędów wymienionych za poleceniem <code>merge</code> jest
już złączony z innym błędem, wtedy wszystkie zgłoszenia mające związek z
którymkolwiek z nich będą połączone. Funkcja łączenia jest jak znak równości:
zwrotna, przechodnia i symetryczna.</p>

<P>Łą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.
</p>

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

<dt><code>unmerge</code> <var>numer_błędu</var>
<dd>

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.

<p>Jeśli wiele zawiadomień o błędach jest złączonych i chcesz podzielić je na
dwie oddzielne grupy musisz rozdzielić każdy raport z osobna, a później
złączyć je w nową grupę.
</p>

<p>Jednym poleceniem <code>unmerge</code> możesz rozdzielić tylko jedno
zgłoszenie. Jeśli chcesz rozdzielić więcej niż jeden błąd to po prostu
użyj wielu poleceń <code>unmerge</code> w Twojej wiadomości.

<dt><code>tags</code> <var>numer_błędu</var> [ <code>+</code> | <code>-</code> | <code>=</code> ] <var>znacznik</var>

  <dd>Ustawia znacznik (tag) dla zawiadomienia o błędzie nr
  <var>numer_błędu</var>, Żadne zawiadomienie nie jest
  wysyłane do użytkownika, który złożył zawiadomienie o błędzie.
  <code>+</code> oznacza dodanie, <code>-</code> oznacza usunięcie, a
  <code>=</code> oznacza zignorowanie obecnych znaczników i ustawienie ich od
  początku.
  Domyślną czynnością jest dodanie.

  <p>Przykłady użycia:</p>

  <pre>
        \# to samo co 'tags 123456 + patch'
        tags 123456 patch

        \# to samo co 'tags 123456 + help security'
        tags 123456 help security

        \# dodaje znaczniki 'fixed' i 'pending'
        tags 123456 + fixed pending

        \# usuwa znacznik 'unreproducible'
        tags 123456 - unreproducible

        \# ustawia znaczniki dokładnie na 'moreinfo' i 'unreproducible'
        tags 123456 = moreinfo unreproducible
  </pre>

  <p>Dostępne obecnie znaczniki zawierają <code>patch</code>, <code>wontfix</code>,
  <code>moreinfo</code>, <code>unreproducible</code>, <code>help</code>,
  <code>pending</code>, <code>fixed</code>, 
  <code>fixed-in-experimental</code>, <code>fixed-upstream</code>,
  <code>security</code>,
  <code>upstream</code>, <code>confirmed</code>, <code>d-i</code>,
  <code>ipv6</code>, <code>lfs</code>, <code>l10n</code>,
  <code>potato</code>, <code>woody</code>, <code>sarge</code>,
  <code>sarge-ignore</code>, <code>etch</code>, <code>etch-ignore</code>,
  <code>sid</code>, oraz <code>experimental</code>.

  <p>Aby dowiedzieć się co <a href="Developer#tags">oznaczają</a> zajrzyj do
  ogólnej dokumentacji systemu śledzenia błędów dla rozwijających. 

<dt><code>close</code> <var>numer_błędu</var> [ <var>wersja_załatania</var> ] (przestarzałe)
<dd>

Zamyka zawiadomienie o błędzie nr <var>numer_błędu</var>.

<p>Wysyłana jest informacja do użytkownika, który zgłosił 
błąd, ale (w odróżnieniu od wysłania wiadomości na adres
<var>numer_błędu</var><code>-done@bugs.debian.org</code>) tekst wiadomości, który
spowodował zamknięcie błędu <strong>nie</strong> jest dołączony do wysyłanej
informacji. Opiekun, który zamyka zawiadomienie musi się upewnić,
prawdopodobnie przez wysłanie osobnej wiadomości, że użytkownik który złożył
zawiadomienie o błędzie wie dlaczego jest on zamykany. Z tego powodu używanie
tego polecenia jest przestarzałe. Zapoznaj się z informacjami dla rozwijających
o tym <a href="Developer#closing">jak poprawnie zamykać błędy</a>.

<p>Jeśli podasz <var>numer_załatania</var>, system kontroli błędów
odnotuje, że błąd został naprawiony w tej wersji pakietu.

<dt><code>package</code> [ <var>nazwa_pakietu</var> ... ]

  <dd>Ogranicza dalsze polecenia tak aby działały wyłączenie na błędach
  dotyczących wymienionych pakietów. Możesz podać jeden lub więcej pakietów.
  Jeśli nie podasz żadnego dalsze polecenia odniosą się do wszystkich
  błędów. Zachęcamy do używania tego polecenia dla bezpieczeństwa, w razie
  gdybyś przypadkiem użył złych numerów błędów.

  <p>Przykładowe użycie:</p>

  <pre>
        package foo
        reassign 123456 bar 1.0-1

        package bar
        retitle 123456 bar: bar sucks
        severity 123456 normal

        package
        severity 234567 wishlist
  </pre>

<dt><code>owner</code> <var>numer_błędu</var> <var>adres</var> | <code>!</code>

  <dd>Ustawia <var>adres</var> jako właściciela 
  zgłoszenia #<var>numer_błędu</var>. Właściciel zgłoszenia jest
  odpowiedzialny za jego naprawienie i będzie otrzymywał wszelkie
  wiadomości dotyczące go. Jest to szczególnie przydatne dla dzielenia
  pracy w przypadkach gdy pakietem zajmuje się grupa opiekunów.

  <p>Jeśli chcesz zostać właścicielem swojego zgłoszenia, możesz użyć
   skrótu <code>!</code> lub określić swój adres email.</p>

<dt><code>noowner</code> <var>numer_błędu</var>

  <dd>Usuwa wszelkie informacje o właścicielach innych niż opiekun.
  Jeśli zgłoszenie nie miało właściciela wtedy nic nie robi.

<dt><code>#</code>...

  <dd>Jednoliniowy komentarz. <code>#</code> musi znajdować się na początku
  linii. Treść komentarzy będzie załączony w potwierdzeniu wysyłanym do
  zgłaszającego oraz do odpowiednich opiekunów, więc możesz ich używać do
  wyjaśniania powodów poszczególnych poleceń.

<dt><code>quit</code>
<dt><code>stop</code>
<dt><code>thank</code>...
<dt><code>--</code>...

  <dd>Oznajmia serwerowi kontroli aby przestał przetwarzać wiadomość. Reszta
  wiadomości może zawierać wyjaśnienia, sygnaturki lub cokolwiek innego. Nic z
  tych rzeczy nie zostanie wykryte przez serwer.

</dl>

<hr>

#use "otherpages.inc"

#use "$(ENGLISHDIR)/Bugs/footer.inc"