1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
|
#use wml::debian::template title="Debian BTS — serwer kontroli" NOHEADER=yes NOCOPYRIGHT=true
#include "$(ENGLISHDIR)/Bugs/pkgreport-opts.inc"
#use wml::debian::translation-check translation="909e4d81e75c25edade771913533aa0f532e9074"
<h1>Wprowadzenie do pocztowego serwera kontroli i manipulacji błedów</h1>
<p>
Tak jak <code>request@bugs.debian.org</code> pozwala <a
href="server-request"> pobierać dane i dokumentację o błędach przy użyciu
poczty elektronicznej</a>, tak <code>control@bugs.debian.org</code> pozwala
w różny sposób operować na zgłoszeniach błędów.
</p>
<p>
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.
</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 wywołane przez nią zmiany są zapisywane w
zgłoszeniu błędu, tym samym są dostępne poprzez strony WWW.
</p>
<p>
Szczegółowe informacje na temat podstaw obsługi serwera i wspólne polecenia
dla obu adresów można znaleźć pod adresem
<a href="server-request#introduction">wprowadzenie do serwera żądań</a>
dostępnym na stronach WWW, w pliku <code>bug-log-mailserver.txt</code> lub
pobrać je wysyłając polecenie <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 do pobrania wysyłając wiadomość z poleceniem <code>refcard</code>.
</p>
<h1>Polecenia dostępne dla pocztowego serwera kontroli</h1>
<table style="margin-left:auto;margin-right:auto">
<tr>
<td align="center">Podstawowe</td>
<td align="center">Wersjonowanie</td>
<td align="center">Duplikaty</td>
<td align="center">Różne</td>
</tr>
<tr>
<!-- General -->
<td valign="top">
<ul class="nodecoration">
<li><a href="#reassign">reassign</a></li>
<li><a href="#severity">severity</a></li>
<li><a href="#tag">tags</a></li>
<li><a href="#retitle">retitle</a></li>
<li><a href="#submitter">submitter</a></li>
<li><a href="#affects">affects</a></li>
<li><a href="#summary">summary</a></li>
<li><a href="#outlook">outlook</a></li>
</ul>
</td>
<!-- Versioning -->
<td valign="top">
<ul class="nodecoration">
<li><a href="#found">found</a> | <a href="#notfound">notfound</a></li>
<li><a href="#fixed">fixed</a> | <a href="#notfixed">notfixed</a></li>
<li><a href="#reopen">reopen</a></li>
<!-- <dt>(close)</dt> Deprecated -->
</ul>
</td>
<!-- Duplicates -->
<td valign="top">
<ul class="nodecoration">
<li><a href="#merge">merge</a> | <a href="#unmerge">unmerge</a></li>
<li><a href="#forcemerge">forcemerge</a></li>
<li><a href="#clone">clone</a></li>
</ul>
</td>
<!-- Misc. -->
<td valign="top">
<ul class="nodecoration">
<li><a href="#thanks">thanks</a></li>
<li><a href="#comment">#</a></li>
<li><a href="#forwarded">forwarded</a> | <a href="#notforwarded">notforwarded</a></li>
<li><a href="#owner">owner</a> | <a href="#noowner">noowner</a></li>
<li><a href="#block">block</a> | <a href="#unblock">unblock</a></li>
<li><a href="#archive">archive</a> | <a href="#unarchive">unarchive</a></li>
<li><a href="server-request#user">user</a> |
<a href="server-request#usertag">usertag</a> |
<a href="server-request#usercategory">usercategory</a></li>
</ul>
</td>
</tr>
</table>
<dl>
<dt><a name="reassign"><code>reassign</code> <var>numer_błędu</var>
<var>pakiet</var> [ <var>wersja</var> ]</a></dt>
<dd>
<p>
Zapisuje informację, że błąd #<var>numer_błędu</var> dotyczy podanego
<var>pakietu</var>.
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).
</p>
<p>
Jeżeli będzie podana <var>wersja</var> pakietu, system kontroli błędów
odnotuje, że błąd dotyczy tej wersji nowo przypisanego pakietu.
</p>
<p>
Można przypisać błąd do dwóch pakietów jednocześnie poprzez
oddzielenie nazw przecinkiem. <em>Jednakże</em> należy to robić tylko,
jeżeli błąd może być naprawiony przez zmianę <em>jednego</em>
z wymienionych pakietów. W innym przypadku należy
<a href="#clone">skopiować</a> błąd i przypisać go do drugiego pakietu.
</p>
</dd>
<dt><a name="reopen"><code>reopen</code> <var>numer_błędu</var>
[ <var>adres-twórcy</var> | <code>=</code> | <code>!</code> ]</a></dt>
<dd>
<p>
Ponownie otwiera błąd #<var>numer_błędu</var> i usuwa wszystkie
poprawione wersje jeśli jest on zamknięty.
</p>
<p>
Domyślnie, lub jeżeli poda się znak <code>=</code>, osoba pierwotnie
zgłaszająca błąd wciąż pozostaje twórcą raportu, więc otrzyma ona
potwierdzenie w momencie ponownego zamknięcia błędu.
</p>
<p>
Jeżeli poda się <var>adres-twórcy</var>, twórca zostanie zmieniony
na podany adres. Aby zostać twórcą ponownie otwieranego zgłoszenia,
należy użyć skrótu <code>!</code> lub podać własny adres pocztowy.
</p>
<p>
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.
</p>
<p>
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 <code>submitter</code>;
należy zauważyć, że to polecenie powiadomi o zmianie pierwotnego autora.
</p>
<p>
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
<code>found</code>.
</p>
</dd>
<dt><a name="found"><code>found</code> <var>numer_błędu</var> [
<var>wersja</var> ]</a></dt>
<dd>
<p>
Zapisuje informację, że błąd #<var>numer_błędu</var> znaleziono w
podanej <var>wersji</var> pakietu do którego został przypisany.
<var>Wersja</var> może być podana w pełnej postaci wg schematu
<var>nazwa_pakietu/wersja</var>.
</p>
<p>
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.
</p>
<p>
Jeżeli nie podano <var>wersji</var>, wtedy lista wersji z poprawionym
błędem jest czyszczona. Jest to działanie identyczne do polecenia
<code>reopen</code>.
<var>Wersja</var> może być podana w pełnej postaci wg schematu
<var>nazwa_pakietu/wersja</var>.
</p>
<p>
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
<var>wersję</var>, do znalezionych błędów w wersji równej lub większej
niż najwyższa <var>wersja</var> oznaczona jako poprawiona. (Aby oznaczyć
błąd jako niepoprawiony (ang. not done) należy użyć polecenia
<code>reopen</code> w połączeniu z poleceniem <code>found</code>.)
</p>
<p>
Komenda została wprowadzona aby zastąpić polecenie <code>reopen</code>, ponieważ
dodanie <var>wersji</var> do składni tego polecenia bez wprowadzania niejasności
byłoby trudnym zadaniem.
</p>
</dd>
<dt><a name="notfound"><code>notfound</code> <var>numer_błędu</var>
<var>wersja</var></a></dt>
<dd>
<p>
Usuwa zapis o tym, że #<var>numer_błędu</var> został zarejestrowany
w podanej <var>wersji</var> pakietu, do którego został dołączony.
<var>Wersja</var> może być podana w pełnej postaci wg schematu
<var>nazwa_pakietu/wersja</var>.
</p>
<p>
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.
</p>
</dd>
<dt><a name="fixed"><code>fixed</code> <var>numer_błędu</var>
<var>wersja</var></a></dt>
<dd>
<p>
Wskazuje, że błąd #<var>numer_błędu</var> został poprawiony
w podanej <var>wersji</var> pakietu, do którego został przypisany.
<var>Wersja</var> może być podana w pełnej postaci wg schematu
<var>nazwa_pakietu/wersja</var>.
</p>
<p>
<em>Nie</em> 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.
</p>
</dd>
<dt><a name="notfixed"><code>notfixed</code> <var>numer_błędu</var>
<var>wersja</var></a></dt>
<dd>
<p>
Usuwa zapis, że błąd #<var>numer_błędu</var> został poprawiony
w podanej <var>wersji</var>.
<var>Wersja</var> może być podana w pełnej postaci wg schematu
<var>nazwa_pakietu/wersja</var>.
</p>
<p>
Polecenie jest równoważne poleceniu <code>found</code>, po którym
wydano polecenie <code>notfound</code> (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 <code>found</code>, a nie <code>notfixed</code>.
</p>
</dd>
<dt><a name="submitter"><code>submitter</code> <var>numer_błędu</var>
<var>adres-twórcy</var> | <code>!</code></a></dt>
<dd>
<p>
Zmienia twórcę zgłoszenia #<var>numer_błędu</var> na
<var>adres-twórcy</var>.
</p>
<p>
Aby zostać nowym twórcą raportu należy użyć skrótu <code>!</code>
lub podać własny adres pocztowy.
</p>
<p>
Podczas gdy polecenie <code>reopen</code> zmienia twórcę innych
błędów powiązanych z błędem ponownie otwieranym, <code>submitter</code>
nie ma wpływu na powiązane błędy.
</p>
</dd>
<dt><a name="forwarded"><code>forwarded</code> <var>numer_błędu</var>
<var>adres</var></a></dt>
<dd>
<p>
Zawiadamia, że błąd <var>numer_błędu</var> został przesłany do
autora kodu źródłowego (upstream maintainer) na podany <var>adres</var>.
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. <var>Adres</var> 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.
</p>
<p>
Przykład użycia:
</p>
<pre>
forwarded 12345 http://bugz.illa.foo/cgi/54321
</pre>
</dd>
<dt><a name="notforwarded"><code>notforwarded</code>
<var>numer_błędu</var></a></dt>
<dd>
<p>
Usuwa informację, że <var>numer_błędu</var> 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.
</p>
</dd>
<dt><a name="retitle"><code>retitle</code> <var>numer_błędu</var>
<var>nowy_tytuł</var></a></dt>
<dd>
<p>
Zmienia tytuł zawiadomienia na podany w poleceniu (domyślnie pobierane
jest pole <code>Subject</code> 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.
</p>
</dd>
<dt><a name="severity"><code>severity</code> <var>numer_błędu</var>
<var>stopień_ważności</var></a></dt>
<dd>
<p>
Ustawia stopień ważności (severity) dla zgłoszenia #<var>numer_błędu</var> na podany <var>stopień</var>.
Nie jest wysyłane powiadomienie do użytkownika zgłaszającego błąd.
</p>
<p>
Stopnie ważności to <bts_severities>.
</p>
<p>
Opis <a href="Developer#severities">co oznaczają poszczególne stopnie</a>
znajduje się w podstawowej dokumentacji dla deweloperów dotyczącej
systemu śledzenia błędów.
</p>
</dd>
<dt><a name="affects"><code>affects</code> <var>numer_błędu</var>
[ <code>+</code> | <code>-</code> | <code>=</code>
] <var>pakiet</var> [ <var>pakiet</var> ... ]</a></dt>
<dd>
<p>
Oznacza, że błąd ma wpływ na inny pakiet. W przypadku, gdy
<var>numer_błędu</var> powoduje problemy w <var>pakiecie</var>
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 <var>pakietów</var>.
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 <code>=</code> określa, że błąd wpływa
na podaną listę pakietów i jest domyślną akcją jeżeli nie podano
pakietów; znak <code>-</code> usuwa podane pakiety z listy pakietów,
na które ma wpływ dany błąd; znak <code>+</code> dodaje podane pakiety
do listy pakietów i jest domyślną akcją jeżeli podano pakiety.
</p>
</dd>
<dt><a name="summary"><code>summary</code> <var>numer_błędu</var>
[<var>numer_wiadomości</var> | <var>podsumowanie</var>]</a></dt>
<dd>
<p>
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.
</p>
<p>
Jeżeli nie podano <var>numeru wiadomości</var>, podsumowanie jest
czyszczone. <var>Numer wiadomości</var> 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).
</p>
<p>
Jeżeli <var>numer wiadomości</var> nie jest liczbą i nie jest pustym
tekstem, przyjmuje się że jest to tekst, który należy ustawić jako
podsumowanie.
</p>
</dd>
<dt><a name="outlook"><code>outlook</code> <var>numer_błędu</var>
[<var>numer_wiadomości</var> | <var>tekst</var>]</a></dt>
<dd>
<p>
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).
</p>
<p>
Jeżeli nie podano <var>numeru wiadomości</var> opis jest
czyszczony. <var>Numer wiadomości</var> 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).
</p>
<p>
Jeżeli <var>numer wiadomości</var> 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.
</p>
</dd>
<dt><a name="clone"><code>clone</code> <var>numer_błędu</var> <var>nowy_numer_ID</var>
[ <var>nowe_numery_ID</var> ... ]</a></dt>
<dd>
<p>
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. <q><var>Nowe numery ID</var></q> 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.
</p>
<p>
Przykład użycia:
</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>
</dd>
<dt><a name="merge"><code>merge</code> <var>numer_błędu</var>
<var>numer_błędu</var> ...</a></dt>
<dd>
<p>
Łą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ń.
</p>
<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
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ń
<code>reassing</code>, <code>reopen</code> itd., aby mieć pewność, że
wszystkie zgłoszenia mają ustawiony taki sam stan przed użyciem polecenia
<code>merge</code>. 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.
</p>
<p>
Jeśli którykolwiek z błędów wymienionych w poleceniu <code>merge</code>
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.
</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.
</p>
</dd>
<dt><a name="forcemerge"><code>forcemerge</code> <var>numer_błędu</var>
<var>numer_błędu</var> ...</a></dt>
<dd>
<p>
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 <code>merge</code>. 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.
</p>
<p>
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.
</p>
</dd>
<dt><a name="unmerge"><code>unmerge</code> <var>numer_błędu</var></a></dt>
<dd>
<p>
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>
<p>
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ę.
</p>
<p>
Jednym poleceniem <code>unmerge</code> 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ń <code>unmerge</code>.
</p>
</dd>
<dt><a name="tags"><!-- match tags too --></a><a name="tag"><code>tags</code> <var>numer_błędu</var> [ <code>+</code> |
<code>-</code> | <code>=</code> ] <var>tag</var> [ <var>tag</var>
... ] [ <code>+</code> | <code>-</code>
| <code>=</code> <var>tag</var> ... ] ]</a></dt>
<dd>
<p>
Ustawia znaczniki (tags) dla zgłoszenia o błędzie #<var>numer_błędu</var>.
Nie jest wysyłane żadne powiadomienie do osoby, która zgłosiła błąd.
Ustawienie akcji na <code>+</code> oznacza dodanie wszystkich znaczników
(<var>tag</var>) podanych po znaku, akcja <code>-</code> oznacza
usunięcie wszystkich znaczników podanych po znaku, akcja <code>=</code>
oznacza ustawienie znaczników na te podane po znaku. Operacja
<code>+</code>, <code>-</code> i <code>=</code> zmienia akcję dla
znaczników podanych po danej operacji. Domyślną akcją jest dodanie
znacznika.
</p>
<p>
Przykłady użycia:
</p>
<pre>
\# 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
</pre>
<p>
Obecnie są obsługiwane następujące znaczniki <bts_tags>.
</p>
<p>
Opis <a href="Developer#tags">znaczenia</a> poszczególnych znaczników
znajduje się w ogólnej dokumentacji dla deweloperów dotyczącej systemu
śledzenia błędów.
</p>
</dd>
<dt><a name="block"><code>block</code> <var>numer_błędu</var> <code>by</code>
<var>błąd</var> ...</a></dt>
<dd>
Polecenie oznacza, że poprawka do pierwszego błędu jest blokowana przez
podane błędy.
</dd>
<dt><a name="unblock"><code>unblock</code> <var>numer_błędu</var>
<code>by</code> <var>błąd</var> ...</a></dt>
<dd>
Polecenie oznacza, że poprawka do pierwszego błędu nie jest już blokowana
przez podane błędy.
</dd>
<dt><a name="close"><code>close</code> <var>numer_błędu</var> [
<var>wersja_poprawiona</var> ] (przestarzałe)</a></dt>
<dd>
<p>
Zamyka zgłoszenie o błędzie #<var>numer_błędu</var>.
</p>
<p>
Do osoby zgłaszającej błąd jest wysyłana informacja, ale (w odróżnieniu od
wysłania wiadomości na adres <var>numer_błędu</var><code>-done@bugs.debian.org</code>)
treść wiadomości, która spowodowała zamknięcie błędu, <strong>nie</strong>
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,
<a href="Developer#closing">jak prawidłowo zamknąć błąd</a> znajdują się
w dokumentacji dla deweloperów.
</p>
<p>
Jeżeli będzie podany parametr <var>wersja_poprawiona</var>,
system śledzenia błędów zapisze, że błąd poprawiono w podanej
wersji pakietu.
</p>
</dd>
<dt><a name="package"><code>package</code> [ <var>nazwa_pakietu</var> ...
]</a></dt>
<dd>
<p>
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.
</p>
<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>
</dd>
<dt><a name="owner"><code>owner</code> <var>numer_błędu</var>
<var>adres</var> | <code>!</code></a></dt>
<dd>
<p>
Ustawia <var>adres</var> jako <q>właściciela</q> błędu #<var>numer_błędu</var>.
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.
</p>
<p>
Aby zostać właścicielem podanego błędu, można użyć skrótu
<code>!</code> lub podać własny adres email.
</p>
</dd>
<dt><a name="noowner"><code>noowner</code> <var>numer_błędu</var></a></dt>
<dd>
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.
</dd>
<dt><a name="archive"><code>archive</code> <var>numer_błędu</var></a></dt>
<dd>
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.
</dd>
<dt><a name="unarchive"><code>unarchive</code> <var>numer_błędu</var></a></dt>
<dd>
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.
</dd>
<dt><a name="comment"><code>#</code>...</a></dt>
<dd>
Jednoliniowy komentarz. <code>#</code> 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ń.
</dd>
<dt><a name="thanks"><code>quit</code></a></dt>
<dt><code>stop</code></dt>
<dt><code>thank</code></dt>
<dt><code>thanks</code></dt>
<dt><code>thankyou</code></dt>
<dt><code>thank you</code></dt>
<dt><code>--</code></dt>
<!-- #366093, I blame you! -->
<!-- <dt><code>kthxbye</code></dt> -->
<!-- See... I documented it! -->
<dd>
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.
</dd>
</dl>
<hr />
#use "otherpages.inc"
#use "$(ENGLISHDIR)/Bugs/footer.inc"
|