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, 437 deletions

diff --git a/polish/Bugs/Developer.wml b/polish/Bugs/Developer.wml
deleted file mode 100644
index 63c4860b4b5..00000000000
--- a/polish/Bugs/Developer.wml
+++ /dev/null
@@ -1,437 +0,0 @@
-#use wml::debian::template title="System śledzenia błędów - informacje dla rozwijających" NOHEADER=yes NOCOPYRIGHT=true
-#use wml::debian::translation-check translation="1.63"
-
-<h1>Informacje dla rozwijających dotyczące systemu śledzenia błędów</h1>
-
-<p>Pierwszym etapem jest nadesłanie zgłoszenia w postaci zwykłej wiadomości
-poczty elektronicznej na adres <code>submit@bugs.debian.org</code>. Zgłoszeniu zostaje nadany
-numer, zgłaszająca osoba otrzymuje potwierdzenie, a zgłoszenie jest
-przekazywane na listę <code>debian-bugs-dist</code>. Jeśli zgłaszający dodał
-nagłówek <code>Package</code> zawierający nazwę pakietu, którego opiekun jest
-znany, kopia zgłoszenia zostaje wysłana także do opiekuna.</p>
-
-<p>Na początku nagłówka <code>Subject</code> zostaje dodany napis
-<code>Bug#</code><var>nnn</var><code>:</code>, a nagłówek
-<code>Reply-To</code> zostaje ustawiony tak, by zawierał zarówno adres
-zgłaszającego jak i <var>nnn</var><code>@bugs.debian.org</code>.</p>
-
-<hrline>
-
-<ul>
-  <li><a href="#closing">Zamykanie zgłoszenia błędu</a></li>
-  <li><a href="#followup">Wiadomości e-mail związane ze zgłoszeniem</a></li>
-  <li><a href="#severities">Stopnie ważności błędów</a></li>
-  <li><a href="#tags">Znaczniki przy zgłoszeniach</a></li>
-  <li><a href="#forward">Zaznaczanie faktu przekazania zgłoszenia błędu</a></li>
-  <li><a href="#owner">Zmiana właściciela błędu</a></li>
-  <li><a href="#maintincorrect">Nieprawidłowo przyporządkowani opiekunowie</a></li>
-  <li><a href="#requestserv">Powtórne otwieranie, przekierowywanie i
-  inne manipulacje na zgłoszeniach</a></li>
-  <li><a href="#subscribe">Subskrypcja błędów</a></li>
-  <li><a href="#subjectscan">Częściowo wycofana opcja skanowania tematów</a></li>
-  <li><a href="#x-debian-pr">Wycofana opcja <code>X-Debian-PR: quiet</code></a></li>
-</ul>
-
-<hrline>
-
-
-<h2><a name="closing">Zamykanie zgłoszenia błędu</a></h2>
-
-<p>Zgłoszenia błędów w Debianie powinny być zamykane w momencie usunięcia
-problemu. Problemy w pakietach można uznać za rozwiązane tylko wtedy, gdy
-pakiet zawierający poprawkę dla danego błędu trafi do archiwum Debiana.</p>
-
-<p>Zazwyczaj jedynymi osobami uprawnionymi do zamykania zgłoszenia są
-zgłaszający ten błąd i opiekun(owie) danego pakietu. Są jednak wyjątki od tej
-reguły, na przykład w przypadku błędów zgłoszonych w nieznanych pakietach lub
-w niektórych pseudo-pakietach. Jeśli masz wątpliwości, nie zamykaj zgłoszenia
-- poproś o radę na liście debian-devel.</p>
-
-<p>Zgłoszenia należy zamykać przez wysłanie wiadomości e-mail na adres
-<var>nnn</var><code>-done@bugs.debian.org</code>. Treść wiadomości musi
-zawierać objaśnienie sposobu, w jaki został poprawiony dany błąd.</p>
-
-<p>Dzięki wiadomościom e-mail wysyłanym przez system śledzenia błędów
-zamknięcie zgłoszenia sprowadza się do odpowiedzenia na taki list po
-uprzedniej zmianie pola <code>To</code> na
-<var>nnn</var><code>-done@bugs.debian.org</code> zamiast
-<var>nnn</var><code>@bugs.debian.org</code> (adres <var>nnn</var><code>-done</code> ma
-też alias <var>nnn</var><code>-close</code>).</p>
-
-<p>Jeśli to możliwe, proszę podać linię <code>Version</code> w
-<a href="Reporting#pseudoheader">pseudo-nagłówku</a> Twojej wiadomości podczas
-zamykania błędu, by system zarządzania błędami wiedział które wydanie paczki
-zawiera poprawkę.</p>
-
-<p>Osoba zamykająca zgłoszenie, osoba która zgłosiła błąd oraz lista
-<code>debian-bugs-closed</code> otrzymają powiadomienie dotyczące zmiany stanu
-danego zgłoszenia. Do zgłaszającego oraz na listę zostanie także wysłana
-wiadomość zawierająca treść wiadomości wysłanej na adres
-<var>nnn</var><code>-done</code>.</p>
-
-
-<h2><a name="followup">Wiadomości e-mail związane ze zgłoszeniem</a></h2>
-
-<p>System śledzenia błędów dodaje do nagłówka <code>Reply-To</code>
-przekazywanej wiadomości adres osoby zgłaszającej błąd oraz adres błędu
-(<var>nnn</var><code>@bugs.debian.org</code>). Należy zwrócić uwagę na fakt, 
-że są to dwa oddzielne adresy.</p>
-
-<p>Jeśli rozwijający pragnie odpowiedzieć na zgłoszenie, powinien po prostu
-użyć funkcji odpowiedzi swojego programu pocztowego, adresując list zgodnie z
-nagłówkiem <code>Reply-To</code>. <strong>Nie</strong> spowoduje to zamknięcia
-błędu.</p>
-
-<p>System śledzenia błędów otrzyma wiadomość wysłaną na adres
-<var>nnn</var><code>@bugs.debian.org</code>, przekaże ją do opiekuna pakietu, dopisze do
-zgłoszenia, a także przekaże na listę <code>debian-bugs-dist</code>.</p>
-
-<p>Wysyłając wiadomości do <var>nnn</var><code>-submitter@bugs.debian.org</code>
-należy pamiętać, że otrzyma go też osoba, która zgłosiła błąd, oraz że kopia
-wiadomości zostanie umieszczona w Systemie śledzenia błędów. Wiadomość nie
-zostanie wysłana do osoby przygotowującej paczki.</p>
-
-<p>Jeśli chcesz wysłać wiadomość, która nie nadaje się do przekazania na listę
-<code>debian-bugs-dist</code>, możesz wysłać ją na adres
-<var>nnn</var><code>-quiet@bugs.debian.org</code> lub
-<var>nnn</var><code>-maintonly@bugs.debian.org</code>. Poczta wysyłana na pierwszy z tych
-adresów jest zapisywana w systemie śledzenia błędów, ale nie jest przekazywana
-do żadnych osób ani list dyskusyjnych. Poczta wysyłana na adres
-<var>nnn</var><code>-maintonly@bugs.debian.org</code> jest zapisywana w systemie i
-przekazywana tylko do opiekuna danego pakietu.</p>
-
-<p><em>Nie</em> należy używać opcji <q>odpowiedz wszystkim</q> programu pocztowego,
-chyba że samodzielnie usunie się pewnych adresatów. Należy zwrócić uwagę na
-to, aby nie wysyłać wiadomości dotyczących istniejących zgłoszeń na adres
-<code>submit@bugs.debian.org</code>.</p>
-
-<p>Więcej informaji o nagłówkach powstrzymujących wiadomości potwierdzające
-(ACK) oraz o wysyłaniu kopii listów za pomocą Systemu śledzenia błędów jest
-dostępnych w <a href="Reporting">instrukcji zgłaszania błędów</a>.</p>
-
-<h2><a name="severities">Stopnie ważności błędów</a></h2>
-
-<p>System śledzenia błędów zapisuje stopień ważności każdego ze zgłoszonych 
-błędów. Jest on domyślnie ustawiony na <q>zwykły</q> (ang. 
-<i><code>normal</code></i>), ale można go zmienić dodając do zgłoszenia 
-pseudo-nagłówek <code>Severity</code> (patrz <a href="Reporting#pseudoheader">
-Jak zgłosić błąd</a>) lub przy pomocy polecenia <code>severity</code> 
-<a href="#requestserv">serwera pocztowego</a>.</p>
-
-<p>Dostępne są następujące stopnie ważności:
-
-<dl>
-<dt><code>krytyczny</code> (ang. <code>critical</code>)
-<dd>powoduje uszkodzenie niezwiązanego oprogramowania w systemie (lub całego
-systemu) lub powoduje poważne utraty danych albo powoduje dziurę w
-bezpieczeństwie systemów, na których instaluje się dany pakiet.
-
-<dt><code>bardzo&nbsp;poważny</code> (ang. <code>grave</code>)
-<dd>uniemożliwia w ogóle lub w większej części korzystanie z danego pakietu
-lub powoduje utratę danych, albo powoduje dziurę w bezpieczeństwie pozwalającą
-na uzyskanie dostępu do kont użytkowników danego pakietu.
-
-<dt><code>poważny</code> (ang. <code>serious</code>)
-<dd>jest <a href="http://release.debian.org/etch_rc_policy.txt">poważnym
-naruszeniem polityki Debiana</a> (to znaczy narusza dyrektywę
-&quot;musi&quot; (ang <i>&quot;must&quot;</i>) lub &quot;wymagany&quot; (ang.
-<i>&quot;required&quot;</i>), lub, w opinii opiekuna pakietu, powoduje, że
-pakiet nie nadaje się do wydania.
-
-<dt><code>ważny</code> (ang. <code>important</code>)
-<dd>błąd mający duży wpływ na użyteczność danego pakietu, nie powodujący
-jednocześnie jego całkowitej bezużyteczności dla kogokolwiek. Aby poznać
-kompletne zasady dotyczące tego, jakie problemy zasługują na te stopnie
-ważności</dd>
-
-<dt><code>zwykły</code> (ang. <code>normal</code>)
-<dd>wartość domyślna, pasująca do większości błędów.
- 
-<dt><code>drobny</code> (ang. <code>minor</code>)
-<dd>problem nie powodujący uszczerbku w użyteczności pakietu, prawdopodobnie
-bardzo łatwy do usunięcia.
-
-<dt><code>życzenie</code> (ang. <code>wishlist</code>)
-<dd>odpowiedni w przypadku prośby o jakąś funkcję, a także w przypadku błędów,
-które są bardzo trudne do usunięcia z powodu założeń projektowych.
-</dl>
-
-<p><strong>Uwaga:</strong> przy ustawianiu stopnia ważności błędu należy używać
-angielskich nazw. Serwer obsługujący te żądania nie zna ich polskich (ani
-żadnych innych) tłumaczeń.</p>
-
-<p>Pewne stopnie ważności są traktowane jako 
-<em><a href="http://bugs.debian.org/release-critical/">uniemożliwiające
-wydanie (ang. <i>release-critical</i>)</a></em>, co znaczy, że błąd ten będzie
-miał wpływ na to, czy dany pakiet zostanie wydany w stabilnej edycji Debiana.
-Obecnie status taki mają stopnie <strong>krytyczny</strong>,
-<strong>bardzo&nbsp;poważny</strong> i <strong>poważny</strong>,
- zobacz listę <a
-href="http://release.debian.org/etch_rc_policy.txt">problemów
-krytycznych dla wydania Etch</a>.</p>
-
-<h2><a name="tags">Znaczniki przy zgłoszeniach</a></h2>
-
-<p>Każdy błąd może mieć pewną ilość znaczników. Są one wyświetlane na liście
-błędów dla każdego z pakietów oraz na pełnej liście błędów.</p>
-
-<p>Znaczniki można ustawiać dodając do zgłoszenia pseudo-nagłówek
-<code>Tags</code> (patrz <a href="Reporting#pseudoheader">Jak zgłosić
-błąd</a>), lub przy pomocy polecenia <code>tags</code> <a
-href="#requestserv">serwera pocztowego</a>.
-Znaczniki należy rozdzielać przecinkami lub spacjami.
-
-<p>Dostępne są obecnie następujące znaczniki:
-
-<dl>
-
-<dt><code>patch</code> (łata)
-  <dd>W dzienniku danego błędu dostępna jest łata lub inny opis łatwej
-  procedury prowadzącej do rozwiązania problemu. Jeśli dostępna łata nie
-  rozwiązuje problemu w odpowiedni sposób lub powoduje inne problemy, nie
-  należy używać tego znacznika.
-
-<dt><code>wontfix</code> (nie naprawię)
-  <dd>Ten błąd nie zostanie naprawiony. Może tak być ponieważ jest to jeden z
-  dwóch równorzędnych sposobów na osiągnięcie jakiegoś celu, a opiekun pakietu
-  i zgłaszający błąd preferują odmienne sposoby. Może tak też być gdy zmiana
-  obecnego zachowania spowoduje inne, gorsze problemy dla innych, itp.
-
-<dt><code>moreinfo</code> (więcej informacji)
-  <dd>Tego błędu nie da się rozwiązać, jeśli zgłaszający nie dostarczy więcej
-  informacji w sensownym czasie (rzędu kilku miesięcy). Znacznik ten przydaje
-  się przy błędach typu: &quot;Nie działa.&quot; Co nie działa?
-
-<dt><code>unreproducible</code> (nie da się powtórzyć)
-  <dd>Tego błędu nie da się powtórzyć w systemie opiekuna. Do zdiagnozowania
-  przyczyny problemu potrzebna jest pomoc osób trzecich.
-
-<dt><code>help</code> (pomocy)
-  <dd>Opiekun prosi o pomoc w rozwiązaniu tego błędu.
-
-<dt><code>pending</code> (poprawiany)
-  <dd>Znaleziono rozwiązanie problemu, wkrótce błąd powinien być poprawiony.
-
-<dt><code>fixed</code> (poprawiony)
-  <dd>Ten błąd jest poprawiony, całkowicie lub tymczasowo (na przykład przez
-  wersję stworzoną przez osobę nie będącą opiekunem tego pakietu), ale mimo to
-  coś trzeba jeszcze zrobić. Ten znacznik zastępuje stary stopień ważności
-  &quot;fixed&quot;.
-
-<dt><code>security</code> (bezpieczeństwo)
-  <dd>Błąd ten opisuje problem z bezpieczeństwem w danym pakiecie (na przykład
-  nieprawidłowe uprawnienia umożliwiające dostęp do danych, które nie powinny
-  być dostępne; błędy przepełnienia bufora umożliwiające niepożądane przejęcie
-  kontroli nad systemem; błędy umożliwiające ataki powodujące odmowę usługi,
-  itp). Większość błędów z tym znacznikiem powinno także mieć stopień ważności
-  &quot;krytyczny&quot; lub &quot;bardzo poważny&quot;.
-
-<dt><code>upstream</code> (źródło)
-  <dd>Ten błąd odnosi się do części pakietu pochodzącej od źródłowego
-  opiekuna.
-
-<dt><code>confirmed</code> (potwierdzony)
-  <dd>Opiekun sprawdził dane zgłoszenie błędu, rozumie je i generalnie zgadza
-  się ze zgłaszającym, ale nie ma jeszcze sposobu na poprawienie błędu. (Użycie
-  tego znacznika jest opcjonalne; jest on przeznaczony głównie dla opiekunów,
-  którzy muszą radzić sobie z dużą ilością otwartych zgłoszeń.)
-
-<dt><code>fixed-upstream</code> (poprawiony przez zewnętrznego opiekuna)
-  <dd>Błąd został naprawiony przez zewnętrznego opiekuna, ale nie znajduje
-  się jeszcze w pakiecie (z jakiegokolwiek powodu: prawdopodobnie zbyt
-  trudno nałożyć poprawki albo zmiany są zbyt małe, by się nimi zajmować).
-
-<dt><code>fixed-in-experimental</code> (poprawiony w dystrybucji
-eksperymentalnej)
-  <dd>Ten błąd został naprawiony w pakiecie znajdującym się w
-  dystrybucji eksperymentalnej, ale jeszcze nie w dystrybucji
-  niestabilnej.
-
-<dt><code>d-i</code>
-  <dd>Ten błąd odnosi się do rozwoju systemu instalacji Debiana
-  (debian-installer). Znacznik ten jest przeznaczony dla takich błędów, które
-  wpływają na rozwój instalatora, mimo że dotyczą pakietów nie będących
-  bezpośrednio jego częścią.
-
-<dt><code>ipv6</code>
-  <dd>Ten błąd wpływa na obsługę protokołu IP w wersji 6.
-
-<dt><code>lfs</code>
-  <dd>Ten błąd wpływa na obsługę dużych plików (ponad 2 gigabajty).
-
-<dt><code>l10n</code>
-  <dd>Ten błąd dotyczy lokalizacji pakietu.
-
-
-<dt><code>potato</code>
-  <dd>Ten błąd odnosi się do wersji znajdującej się w wydaniu Debiana o nazwie
-  kodowej &quot;potato&quot;.
-
-<dt><code>woody</code>
-  <dd>Ten błąd odnosi się do wersji znajdującej się w wersji Debiana o nazwie
-  kodowej &quot;woody&quot;.
-
-<dt><code>sarge</code>
-<dd>Ten błąd odnosi się zwłaszcza do dystrybucji o nazwie kodowej &quot;sarge&quot;.
-
-<dt><code>sarge-ignore</code>
-  <dd>Ten błąd opóźniający wydanie ma być ignorowany na potrzeby wydania
-  sarge. <strong>Ten znacznik powinien być używany tylko przez menedżera
-  wydań. Nie ustawiaj go samodzielnie bez jego wyraźnej zgody.</strong>
-
-<dt><code>etch</code>
-  <dd>Ten błąd odnosi się zwłaszcza do dystrybucji (jeszcze nie wydanej)
-  o nazwie kodowej &quot;etch&quot;.
-
-<dt><code>etch-ignore</code>
-  <dd>Ten błąd typu release-critical ma zostać pominięty w celu
-  wydania dystrybucji etch. <strong>Ten znacznik powinien być użyty jedynie
-  przez menadżera wydań; nie ustawiaj go samodzielnie bez wyraźnej zgody
-  z jego strony.</strong>
-
-<dt><code>sid</code>
-  <dd>Ten błąd odnosi się do wersji znajdującej się w niestabilnej wersji
-  Debiana (o nazwie kodowej &quot;sid&quot;).
-
-<dt><code>experimental</code>
-  <dd>Ten błąd odnosi się do dystrybucji experimental.
-</dl>
-
-<p>Ostatnie pięć znaczników jest używanych głównie przy błędach uniemożliwiających
-wydanie, w przypadku których ważna jest wiedza na temat tego, do których wersji
-Debiana się odnoszą, aby poprawiać (lub usuwać) odpowiednie pakiety.</p>
-
-
-<h2><a name="forward">Zaznaczanie faktu przekazania zgłoszenia błędu</a></h2>
-
-<p>Rozwijający, który przekazuje zgłoszenie błędu opiekunowi źródłowemu
-pakietu, powinien zaznaczyć ten fakt w systemie śledzenia błędów w następujący
-sposób:</p>
-
-<p>W polu <code>To</code> wiadomości e-mail należy umieścić tylko adres(y)
-opiekuna(ów) źródłowego(ych); w polu <code>CC</code> należy umieścić adres
-osoby, która zgłosiła błąd oraz adres
-<var>nnn</var><code>-forwarded@bugs.debian.org</code>.</p>
-
-<p>Należy poprosić osobę wymienioną w polu <code>To</code>, aby pozostawiła
-przy odpowiadaniu adres <var>nnn</var><code>-forwarded@bugs.debian.org</code> w polu
-<code>CC</code>, dzięki czemu jej wiadomość zostanie zapisana razem z resztą
-zgłoszenia.</p>
-
-<p>Kiedy system śledzenia błędów otrzyma wiadomość wysłaną na adres
-<var>nnn</var><code>-forwarded</code>, zaznaczy dany błąd jako przekazany na
-adres wymieniony w polu <code>To</code> danej wiadomości, jeśli błąd nie ma już statusu <q>przekazany</q>.</p>
-
-<p>Można też ustawić informację &quot;przekazane do&quot; przy pomocy
-odpowiedniej wiadomości wysłanej na adres <a
-href="server-control"><code>control@bugs.debian.org</code></a>.</p>
-
-<h2><a name="owner">Zmiana właściciela błędu</a></h2>
-
-<p>Zdarza się, że osoba odpowiedzialna za naprawienie błędu nie jest
-opiekunem danego pakietu (np. gdy pakietem zajmuje się grupa opiekunów).
-W takim przypadku warto odnotować to w systemie śledzenia błędów - każdemu
-błędowi można przypisać właściciela.
-
-<p>Właściciel błędu może zostać ustalone przez podanie linii <code>Owner</code>
-w pseudo-nagłówku podczas zgłoszenia błędu (więcej w <a
-href="Reportin#pseudoheader">instrukcji zgłaszania błędu</a>) lub za pomocą
-poleceń <code>owner</code> i <code>noowner</code> <a
-href="#requestserv">serwera kontroli żądzań</a>.
-
-
-<h2><a name="maintincorrect">Nieprawidłowo przyporządkowani opiekunowie</a></h2>
-
-<p>Najczęściej powodem przyporządkowania do pakietu niewłaściwego opiekuna
-jest to, że opiekun niedawno się zmienił, a nowy opiekun jeszcze nie wysłał na
-serwer nowej wersji pakietu ze zmienionym polem kontrolnym
-<code>Maintainer</code>. Opiekun zostanie zmieniony automatycznie, gdy na
-serwer archiwum zostanie wysłana nowa wersja pakietu. Jeśli jednak nowa wersja
-nie jest wkrótce spodziewana, opiekunowie systemu śledzenia błędów mogą
-ręcznie zmienić tą informację. Można się z nimi skontaktować pod
-adresem <code>override-change@debian.org</code>.
-
-
-<h2><a name="requestserv">Powtórne otwieranie, przekierowywanie i inne manipulacje na zgłoszeniach</a></h2>
-
-<p>Możliwa jest zmiana przyporządkowania błędu do pakietu, powtórne otwarcie
-omyłkowo zamkniętego zgłoszenia, modyfikacja informacji mówiącej o tym do
-kogo, o ile w ogóle, zostało przekazane zgłoszenie, zmiana stopnia ważności
-i tytułu błędu, ustalenia właściciela błędu, połączenie i rozdzielenie raportu
-błedu oraz do zapisu wersji paczek, w których błędy zostały znalezione,
-a także w których zostały poprawione. Można to zrobić wysyłając odpowiednią
-wiadomość na adres <code>control@bugs.debian.org</code>.</p>
-
-<p><a href="server-control">Format tej wiadomości</a> jest opisany w innym
-dokumencie dostępnym na stronie WWW lub w pliku
-<code>bug-maint-mailcontrol.txt</code>. Wersję tekstową tego dokumentu można
-także uzyskać wysyłając słowo <code>help</code> na wymieniony wyżej adres.</p>
-
-<h2><a name="subscribe">Subskrypcja błędów</a></h2>
-
-<p>System śledzenia błędów pozwala także osobom zgłaszającym błedy, deweloperom
-oraz innym zainteresowanym na dołączenie się do subskrypcji pojedynczych błędów.
-Ta opcja może być użyta przez osoby chcące mieć podgląd na dyskusję błedu bez
-konieczności subskrypcji paczki przez PTS. Wszystkie wiadomości wysłane na
-<var>nnn</var><code>@debian.org</code> są wysyłane do osób w subskrypcji.</p>
-
-<p>Subskrybowanie do błędu może być wykonane przez wysłanie wiadomości pod 
-adres <var>nnn</var><code>-subscribe@bugs.debian.org</code>. Temat oraz treść 
-wiadomości są ignorowane przez BTS. Kiedy tylko wiadomość zostanie 
-przetworzona, użytkownikowi jest wysyłana wiadomość potwierdzającą, na którą 
-trzeba odpowiedzieć przed tym jak wiadomości dotyczące tego błedu zostaną do 
-niego wysłane.</p>
-
-<p>Jest także możliwe usunięcie swojego adresu z listy subkrypcji. Można to
-uczynić poprzez wysłanie wiadomości pod adres
-<var>nnn</var><code>-unsubscribe@bugs.debian.org</code>. Temat oraz treść
-wiadomości są ignorowane przez BTS. Użytkownik musi odpowiedzieć na wiadomość
-potwierdzającą, zanim zostanie usunięty z listy.</p>
-
-<p>Domyślnie, adres, który ma zostać dołączony do listy zasubskrybowanych,
-zostaje pobrany z nagłówkA <CODE>from</code>. Jeśli chcesz zapisać inny adres,
-musisz zakodować adres, który ma zostać dopisany do listy. Przybiera to taką postać:
-<var>nnn</var><code>-subscribe-</code><var>localpart</var><code>=</code><var>example.com</var><code>@bugs.debian.org</code>.
-Przykład ten spowodowałby wysłanie na adres <code>localpart@example.com</code> 
-wiadomości subskrypcji do błedu. Część <code>@</code> znaku musi zostać 
-zakodowana poprzez zamienienie do postaci <code>=</code>. Podobnie,
-wypisanie z listy przybiera postać
-<var>nnn</var><code>-unsubscribe-</code><var>localpart</var><code>=</code><var>example.com</var><code>@bugs.debian.org</code>.
-W obu przypadkach temat oraz treść wiadomości zostaną przekazane na adres podany
-w potwierdzeniu wysyłanym przez system.</p>
-
-<h2><a name="subjectscan">Częściowo wycofana opcja skanowania tematów</a></h2>
-
-<p>Wiadomości przychodzące na adres <code>submit@bugs.debian.org</code> lub
-<code>bugs@bugs.debian.org</code>, których adres zaczyna się od
-<code>Bug#</code><var>nnn</var> będą traktowane tak, jakby były wysłane na
-adres <var>nnn</var><code>@bugs.debian.org</code>. Dzieje się tak ze względu 
-na zgodność wstecz jak i na to, aby wyłapywać pocztę wysyłaną na adres
-<code>submit@bugs.debian.org</code> przez pomyłkę (na przykład przez użycie 
-opcji odpowiedzi do wszystkich adresatów).</p>
-
-<p>Podobna zasada obowiązuje dla adresów <code>maintonly</code>,
-<code>done</code>, <code>quiet</code> oraz <code>forwarded</code>,
-które traktują pocztę nadchodzącą ze znacznikiem w tytule jakby nadeszła na
-odpowiadający adres <var>nnn-cośtam</var><code>@bugs.debian.org</code>.</p>
-
-<p>Wiadomości nadchodzące na adresy <code>forwarded@bugs.debian.org</code> i
-<code>done@bugs.debian.org</code> - tzn. bez numeru błędu w adresie, a nie 
-zawierające numeru w temacie, zostają zapamiętane jako 
-&quot;śmieci&quot; przez parę tygodni i zignorowane.</p>
-
-
-<h2><a name="x-debian-pr">Wycofana opcja <code>X-Debian-PR: quiet</code></a></h2>
-
-<p>Kiedyś można było zapobiec przekazywaniu poczty przez system śledzenia
-błędów przez dodanie nagłówka pocztowego <code>X-Debian-PR: quiet</code>.</p>
-
-<p>Nagłówek ten jest teraz ignorowany. Zamiast niego należy używać adresów
-<code>quiet</code> lub <var>nnn</var><code>-quiet</code> (względnie
-<code>maintonly</code> lub <var>nnn</var><code>-maintonly</code>).</p>
-
-<hr>
-
-#use "otherpages.inc"
-
-#use "$(ENGLISHDIR)/Bugs/footer.inc"