Trac
Trac - strona projektu
Trac-Hacks - dodatki, rozszerzenia, itp.
Tłumaczenie terminologii
System zarządzania projektami, śledzenia zmian i zgłaszania błędów
zintegrowane wiki (dokumentacja projektu)
zgłoszenia (ticket subsystem, bug/issue tracking system), etapy, komponenty (raporty, śledzenie postępów)
interfejs do systemów kontroli wersji (SVN browser)
historia (Timeline)
plan prac (roadmap) - harmonogramy
RSS
rozszerzenia (Trac hacks)
Przykłady: Trac Pidgin RPM
Wiki
-
-
CamelCase, [wiki:CamelCase], !CamelCase
tworzenie nowych stron poprzez kliknięcie na link do nieistniejącej strony wiki
TracLinks (
v0.11): pozwalają tworzyć odnośniki niemal do wszystkich elementów Traca. Mogą być używane na stronach wiki, w opisach zgłoszeń i etapów, w komentarzach do zadań, w opisach zatwierdzonych rewizji SVN.
wiki CamelCase
, wiki:CamelCase
, [CamelCase Opis linku]
strona nadrzędna [..]
zgłoszenia #1 lub ticket:1
komentarze do zgłoszeń - comment:1:ticket:2
raporty {1} lub report:1
etapy milestone:1.0
załączniki attachment:example.tgz, attachment:attachment.1073.diff:ticket:944
rewizje r1, [1], changeset:1 lub [1/trunk], changeset:1/trunk
komentarze rewizji r1:3, [1:3] lub log:@1:3, log:trunk@1:3, [2:5/trunk]
różnice diff:@1:3, diff:plugins/0.12/mercurial-plugin@9128:9953, diff:tags/trac-0.9.2/wiki-defaulttags/trac-0.9.3/wiki-default lub diff:trunk/trac@3538sandbox/vc-refactoring@3539
pliki
source:trunk/COPYING
source:/trunk/COPYING@200 (rewizja 200)
source:/trunk/COPYING@200#L25 (rewizja 200, linia 25)
aliasy browser:, repos:
source:/some/file@123:10-20,100,103#L99
historia timeline:2008-01-29, timeline:2008-01-29T15:48, timeline:2008-01-29T15:48Z, timeline:2008-01-29T16:48+01
-
Historia/TimeLine
Automatycznie tworzona historia, zawierająca inf. o:
Opcje:
Przeglądarka źródeł/Repository Browser
Wygodny w użyciu i przejrzysty eksplorator repozytorium SVN:
Plan prac/Road map
Harmonogram prac podzielony na etapy (główne zadania). Każdy etap zawiera szereg związanych z nim zadań (zgłoszeń/tickets) do wykonania.
etapy (milestones) - ich cele i opis (formatowanie wiki), planowany termin zakończenia
automatyczne grupowanie i statystyki zgłoszeń dla planu prac jak i dla poszczególnych etapów
dodawanie/usuwanie/modyfikacja etapów poprzez panel administracyjny
eksport w formacie iCalendar
Zgłoszenia/Ticket system
Zgłoszenie jest pojedynczym zadaniem do wykonania:
zadania do wykonania (task), prośby o nowe funkcje (enhancement), zgłaszanie błędów (defect) i problemów, uwagi, pytania
każde zgłoszenie jest zlecone konkretnej osobie (owner)
zamknięcie zgłoszenia (resolve, closed, fix) - wykonanie zadania, naprawienie błędu, wdrożenie rozszerzenia
-
wszystkie zgłoszenia można edytować, przydzielać właścicielom, określać priorytety, dyskutować/komentować w każdej chwili
opis, komentarze, dyskusja
linki Traca oraz stron wiki pozwalają nawiązać do innych problemów, zgłoszeń, plików, rewizji, stron wiki, itd.
Atrybuty zgłoszeń
Temat (Summary) — Krótki opis.
Zgłaszający (Reporter) — autor zgłoszenia
Typ (Type) — rodzaj np. defect (błąd), enhancement (rozszerzenie), request, task (zadanie)
Component — moduł lub podsystem projektu
Version
Keywords — przydatne przy wyszukiwaniu i tworzeniu raportów
Priority — trivial → blocker.
Etap (Milestone) — When this issue should be resolved at the latest.
Przypisz do (Assigned to/Owner) — wykonawca
Cc — przekazanie kopii do zainteresowanych osób
Resolution — powód zamknięcia: fixed, invalid, wontfix, duplicate, worksforme.
Status — aktualny status: assigned, closed, reopened.
Description — Szczegółowy opis.
klasyfikacją ważności (severity)
inne: można definiować własne (trac.ini), np. system operacyjny (lista wyboru: Windows, Linux, Mac)
Wartości atrybutów zgłoszeń można edytować w panelu administracyjnym.
Możliwe jest tworzenie nowych atrybutów (trac.ini)
Przebieg prac nad zgłoszeniem/Workflow
Przykład (v0.11)

Żródło: http://trac.edgewall.org/chrome/common/guide/basic-workflow.png
Przykład z recenzentem:
Inne przykłady
Cykl życia zgłoszenia - ogólnie
Typowy cykl życia zgłoszenia:
osoba posiadająca uprawnienia do raportowania wprowadza informację o błędzie
osoba lub system określa osobę, której dotyczy błąd i generowane jest powiadomienie
(alerty, email i inne kanały komunikacji),
osoba, która otrzymała powiadomienie, akceptuje go do poprawy lub deleguje ten błąd do innej osoby,
osoba odpowiedzialna kończy pracę nad błędem na jeden z kilku sposobów – informując, że błąd został poprawiony, odłożony w czasie, nie jest możliwy do poprawy czy, że zgłoszenie błędu było niepoprawne,
jeśli błąd usunięto, osoba odpowiednio uprawiona osoba weryfikuje, czy błąd faktycznie został usunięty i zwykle zgłoszenie błędu jest zamykane.
po ostatecznym rozwiązaniu problemu (np. po opublikowaniu albo instalacji u klienta wersji pozbawionej błędu) błąd jest zamykany.
Raporty/View Tickets
Zdefiniowane raporty (Available Reports)
Custom Query - dodawanie filtrów zgłoszeń i określanie wyświetlanych kolumn, zapis zapytania
zapytania mogą dotyczyć każdego atrybutu zgłoszeń: status, temat, właściciel, itd
pola bazy danych: id, type, time, changetime, component, severity, priority, owner, reporter, cc, version, milestone, status, resolution, summary, description, keywords
Tworzenie nowych raportów (zapytań)
[query:?status=new&status=assigned&status=reopened&group=owner Assigned tickets by owner]
[[TicketQuery(version=0.6|0.7&resolution=duplicate)]]
Status zgłoszenia i rozwiązania
SVN & Trac
Przykłady:
svn commit -m "Naprawiono blad. Fixes #1 & #2. "
svn commit -m "Poprawki związane ze zgłoszeniem re #1"
svn commit -m "Blah Blah, Ticket #587 status: Fixed"
svn commit -m "This will close #10 and #12, and add a note to #12."
Składnia:
polecenie #1
polecenie #1 & #2
polecenie #1 and #2
polecenie ticket:1
polecenie ticket:1 & ticket:2
polecenie ticket:1 and ticket:2