Automatic purge of file outdated for six months.

CVS version numbers

catalan/Bugs/Reporting.wml: 1.22 -> 1.23(DEAD) 
polish/Bugs/Developer.wml: 1.31 -> 1.32(DEAD) 
polish/Bugs/Reporting.wml: 1.28 -> 1.29(DEAD) 
polish/Bugs/server-control.wml: 1.16 -> 1.17(DEAD) 
polish/News/2003/20031110.wml: 1.2 -> 1.3(DEAD) 
polish/News/weekly/2001/28/index.wml: 1.16 -> 1.17(DEAD)

1 files changed, 0 insertions, 364 deletions

diff --git a/polish/Bugs/server-control.wml b/polish/Bugs/server-control.wml
deleted file mode 100644
index 833e93b39b3..00000000000
--- a/polish/Bugs/server-control.wml
+++ /dev/null
@@ -1,364 +0,0 @@
-#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> ]
-
-<dd>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>new IDs</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.
-  <q><var>nowe_numery_ID</var></q> 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"