Jak radzisz sobie z powiązanymi błędami w Bugzilli?

Question

W naszym środowisku mamy podstawową bazę kodów oraz kilka implementacji tego kodu bazujących na kliencie. Gdy klient zgłasza problem, musimy ustalić, czy jest to problem specyficzny dla klienta, czy też jest to problem z podstawową wersją kodu.

Używamy Bugzilli do śledzenia błędów, a my mamy produkt bugzilla dla podstawowej bazy kodu, a także dla implementacji klienta (ponieważ dostosowali ofertę, aby mieć ulepszoną funkcjonalność). Kiedy klient zgłasza błąd związany z podstawową bazą kodów, musimy zgłosić ten błąd w 2 produktach bugzilla - core i client - tak, aby oba zespoły wiedzieli o problemie. Najlepiej byłoby, gdybyśmy pomnożyli te błędy, aby nie zmarnować wysiłków próbujących je naprawić dwa razy, a także aby 2 Kierowników Projektu byli w pełni poinformowani o postępach tego problemu.

Mój najlepszy pomysł jak dotąd to skorzystanie z komentarza/opisu zawierającego prace "odnosi się do błędu", ponieważ wydaje się, że słowa bug magicznie stają się linkiem do określonego błędu, co ułatwia dotarcie do szczegółów tego innego błędu. Można go następnie wyszukać za pomocą kryteriów "Komentarz zawiera wyszukiwanie".

Jak robią to inni?

Answer 1

użyłbym zależy/pól bloków, jeżeli są one włączone w Twojej Bugzilla, z następującym workflow, z grubsza:

• błąd w produkcie X-specyficzny klient jest złożony;
• jeśli okaże się, że jest obecny w produkcie podstawowym, inna "podstawowa" wersja tego błędu (błąd Y) jest zapisana w produkcie podstawowym i jest przeznaczona do blokowania błędu specyficznego dla klienta (Y bloki X, X zależy od Y);
• zespół rdzenia przechodzi do naprawiania głównego błędu Y;
• po naprawieniu błędu rdzenia, można również naprawić błąd X specyficzny dla klienta (może to wymagać dodatkowego wysiłku lub nie).

zalet korzystania zależy/bloki zamiast linków w komentarzach to:

• powiadomienia: gdy ktoś zmienia bug Y, każdy kto ogląda robaki X będzie również uzyskać informację;
• Egzekwowanie prawa: Bugzilla może zostać dostrojony, aby nie zezwalać na zamykanie błędów, które zależą od co najmniej jednego otwartego błędu, więc Y będzie musiało być zamknięte zanim X zostanie zamknięte.

Wcześniej używaliśmy podobnej konfiguracji z jednym produktem podstawowym i dwoma produktami produkcyjnymi, które zostały wysłane do klientów. Jednak mieliśmy jeden zespół dla wszystkich produktów, więc jest to prostsze. Błąd został zwykle zgłoszony w produkcie produkcyjnym, po czym albo go tam naprawiliśmy, albo eskalowaliśmy do produktu podstawowego, albo zrobiliśmy duplikat błędu dla innego produktu produkcyjnego. Ilekroć były dwa zgłoszenia błędów dotyczące tego samego problemu, były one powiązane z zależnościami/blokami.