Dlaczego niektóre duże projekty, takie jak Git i Debian, używają tylko listy mailingowej, a nie narzędzia do śledzenia problemów?

65

Śledzenie błędów dla każdego projektu o przyzwoitej wielkości wydaje mi się trochę bezproblemowe - sprawia, że naprawdę łatwo jest zorganizować setki lub tysiące problemów, bez kolizji lub pomieszania.

Więc kiedy widzę kilka naprawdę dużych projektów, takich jak Git, wykorzystujących listę mailingową jako główną metodę koordynowania konserwacji i rozwoju, jestem trochę zdumiony. Przykłady:

Git - strona społeczności :

... Raporty o błędach należy wysyłać na tę listę mailingową.
System śledzenia błędów Debiana według Wikipedii:

... Jego unikalną cechą jest to, że nie ma żadnego interfejsu internetowego do edycji raportów o błędach - wszystkie modyfikacje są dokonywane za pośrednictwem poczty elektronicznej.

Wiele współczesnych programów do śledzenia błędów ma bardzo dobrą integrację z pocztą e-mail (możesz otrzymywać komentarze lub powiadomienia o błędach, które oglądasz lub które zostały Ci przypisane), a także z systemami kontroli wersji (zatwierdzenia można oznaczyć jako rozwiązanie problemu itp. .). Wiele z tego musiałoby być zrobionych ręcznie za pomocą listy mailingowej, a otrzymasz mnóstwo e-maili na temat błędów, które Cię nie interesują.

Jakie są więc główne zalety listy adresowej w porównaniu do internetowego narzędzia do śledzenia błędów? Dlaczego niektóre duże projekty używają tylko listy mailingowej?

— naught101
źródło

2

Tak, nie, zgadzam się z tobą, Git używa list mailingowych :) Mówiłem, że dodajesz do niego „naprawdę duże projekty” i myślałem, że jeśli to zrobisz, powinieneś dać trochę więcej przykłady tych naprawdę dużych projektów. W przeciwnym razie pytanie sprowadza się do „Git używa listy adresowej, dlaczego tak jest?” w takim przypadku odpowiedź Jörga W Mittaga jest bardziej odpowiednia ...

— Shivan Dragon

1

Hmm, cóż, miałem wrażenie, że było ich więcej ... Debian używa systemu opartego na poczcie , choć bardziej złożonego niż lista mailingowa. Ok, ale najważniejsze jest to: „jakie są zalety korzystania z listy mailingowej nad narzędziem do śledzenia błędów?” O ile odpowiedź nie brzmi „nie ma żadnych, programiści git są po prostu ludditami”.

— naught101

@ naught101: dlaczego jesteś zdumiony, kiedy to widzisz? Niestabilna Debian może być instalowana i używana bez widocznego exploita roota wymagającego łatania i bez konieczności ponownego uruchamiania przez sześć miesięcy. To dotyczy niestabilnej wersji Debiana. Zablokowałem serwery Debiana, które osiągnęły czterocyfrowe dni bezawaryjności (żaden pojedynczy exploit root-a wymagający ponownego uruchomienia wpływa na moją konfigurację w tym okresie). Ci faceci mogą nie korzystać z najnowszych trendów technologicznych, ale oczywiście postępują właściwie. W każdej chwili zrezygnowałbym ze śledzenia błędów internetowych dla stabilności Debiana.

— Cedric Martin

2

@CedricMartin: Wiem, zgadzam się. Śledzenie błędów list mailowych wyraźnie działa odpowiednio dla niektórych zespołów, ale nadal wydaje mi się mniej łatwe niż narzędzie do śledzenia błędów. Pomyślałem jednak, że dla głównych twórców projektów różnica może wydawać się bardzo niewielka: i tak śledzą prawie wszystko, co się dzieje. Ale dla początkujących lista mailingowa jest prawie niemożliwa do odczytania, więc nie można uzyskać prostego przeglądu sprawności projektu. Narzędzie do śledzenia błędów pozwala nowym użytkownikom / deweloperom szybko dowiedzieć się, jak porusza się projekt, i dowiedzieć się, jakie ulepszenia są uważane za ważne przez zespół podstawowy.

— naught101

Greg Kroah-Hartman zajmuje się tym, ponieważ dotyczy jądra Linuksa w ramach tej dyskusji . W szczególności: „Nie ma NO sposób github / Gerrit / gitorious modelu będzie działać w ogóle dla jądra Skala, na którym pracujemy to zupełnie inny poziom niż mogłyby być obsługiwane za pomocą tych narzędzi ... Naprawdę nie ma innego.. znany sposób obsługi 10000 łatek co 2 miesiące, w stabilnym wydaniu, z recenzją, z udziałem ponad 3000 programistów, innych niż obecnie. ”

— naught101

45

Obserwowane preferencje wyglądają jak naturalna konsekwencja rekomendacji jasno określonej w Normach Kodowania GNU . Sugeruje się zgłaszanie błędów przez e-mail, jak widać w poniższym cytacie (zaznaczyłem pogrubioną część, która bezpośrednio dotyczy twoich obserwacji):

4.7.2 --help

Standardowa --helpopcja powinna wypisać krótką dokumentację dotyczącą tego, jak wywołać program, na standardowym wyjściu, a następnie pomyślnie zakończyć. Inne opcje i argumenty powinny zostać zignorowane, gdy zostanie to zauważone, a program nie powinien wykonywać swojej normalnej funkcji.

Pod koniec danych ‘--help’wyjściowych opcji umieść wiersze podające adres e-mail do zgłaszania błędów , stronę główną pakietu (normalnie ‘http://www.gnu.org/software/pkg’oraz stronę ogólną z pomocą programów GNU. Format powinien wyglądać następująco:
    Report bugs to: mailing-address
    pkg home page: <http://www.gnu.org/software/pkg/>
    General help using GNU software: <http://www.gnu.org/gethelp/>
Można podać inne odpowiednie listy mailingowe i strony internetowe.

Powyższe preferencje odzwierciedlają z kolei powszechną akceptację poczty elektronicznej jako formy komunikacji elektronicznej. Każdy użytkownik czytający --helpwiadomość, jak sugerowano powyżej, powinien łatwo zrozumieć, co zrobić, jeśli zobaczy błąd - wysyłanie wiadomości jest łatwe.

Tracker problem może być (i myślę, że jest ) lepiej dla programisty pracującego w projekcie, ale dla szerszej publiczności byłoby trudniej przedstawić i wyjaśnić, jak go używać, zwłaszcza przy uwzględnieniu różnorodnych i różnice pomiędzy różnymi ticket tracking .

Jeden projekt może korzystać z Bugzilli, inny będzie trzymał się JIRA, trzeci z ... GNATS itp. Itd. Itd. Po prostu nie ma sposobu, aby przedstawić to „zoo” w sposób, który byłby tak standardowy i jednolity jak

Report bugs to: mailing-address

Uwaga powyżej nie oznacza, że projekty nie powinny używać modułu do śledzenia problemów wewnętrznie . Jak wyjaśniono w doskonałej odpowiedzi na powiązane pytanie ,

Twój moduł do śledzenia błędów służy Twojej wygodzie, a nie Twoim klientom. Jak możesz się czuć, jeśli nie chcesz, aby problem z telefonem lub e-mailem został wprowadzony samodzielnie?

Musisz mieć możliwość wprowadzania problemów i przypisywania ich ręcznie do klienta ...

— komar
źródło

3

Świetna odpowiedź! E-mail jest lepiej znany niż narzędzia do śledzenia problemów i łatwiejszy do zrozumienia (co nie znaczy, że każdy „dostaje” e-maila: P)

— Andres F.

21

Ponadto ta rada GNU jest starożytna, znacznie starsza niż sieć i internetowe narzędzia do śledzenia problemów.

— Ross Patterson

@RossPatterson Myślałem o tym. Ale wydaje się mało prawdopodobne, aby był starszy niż sieć, biorąc pod uwagę, że zawiera wiele adresów URL ...

— naught101

6

@gnat: Główna część tej połączonej odpowiedzi jest tak świetna, że „jeśli jest to dla ciebie łatwe, możesz wprowadzić tego rodzaju rzeczy właśnie tam” . Jest to kluczem do wielu projektów typu open source, ponieważ nie ma środków na wsparcie telefoniczne. Lista mailingowa jest dla mnie wyłączona jako użytkownik zgłaszający błędy, ponieważ nie chcę rejestrować się w celu uzyskania odpowiedzi. Dzięki narzędziu do śledzenia błędów widzę, że mój problem dotyczy systemu, i mogę wrócić i poszukać go później oraz sprawdzić, czy został zaktualizowany. Jest to trudne w przypadku listy mailingowej, chyba że istnieje naprawdę dobry internetowy moduł do śledzenia list, co często nie jest prawdą.

— naught101

1

@ naught101 Może nie jest starszy niż Internet, ale zdecydowanie starszy niż trackery internetowe

— sakisk

30

W szczególności w przypadku Git istnieje prosty historyczny powód: Git został uruchomiony przez hakerów Linuksa dla hakerów Linuksa i wykorzystuje ten sam model programistyczny i narzędzia, co sam Linux. Linux jest jednak starszy niż WWW, więc kiedy Linux został uruchomiony, po prostu nie istniały internetowe narzędzia do śledzenia problemów, ponieważ nie było sieci!

W rezultacie społeczność Linuksa opracowała niezwykle wydajne narzędzia i przepływy pracy do radzenia sobie z raportami błędów i przeglądami kodów za pośrednictwem poczty e-mail, i nie było powodu, aby porzucali całą tę pracę i zaczynali od zera, kiedy rozpoczęli projekt Git.

— Jörg W Mittag
źródło

3

Myślałem, że WWW poprzedza Linuksa. Nieco. Oba zostały bardzo wykonane w tym samym czasie i przez różne grupy ludzi; tak naprawdę dopiero w połowie lat 90.

— Donal Fellows

6

Ok, ale jądro Linuksa ma teraz moduł śledzenia błędów: bugzilla.kernel.org . Oczywiście nie jest to tak duża bariera.

— naught101

7

-1 Git jest znacznie młodszy od sieci. Vintage 2005. W tym czasie było wiele monitorów problemów, w tym oczywiście Bugzilla. Linus po prostu nie lubi śledzenia problemów, a jego słowo jest prawem w tym środowisku.

— Ross Patterson

6

@RossPatterson - Powiedział, że Linux jest starszy od sieci, a nie Git. Nie sądzę, aby twój komentarz uzasadniał głosowanie w dół, ponieważ w zasadzie powtórzyłeś to, co powiedział.

— beatgammit

2

@tjameson Z perspektywy czasu masz rację. Powrót do neutralnego.

— Ross Patterson

17

W przypadku Git:

Na liście mailowej jest kilka dyskusji, w których ludzie proponują użycie jakiegoś narzędzia do śledzenia błędów. Wydaje się, że inicjatywy te zakończyły się niepowodzeniem, dlatego Git nie używa narzędzia do śledzenia błędów prawdopodobnie dlatego, że większość autorów nie uważa go za użyteczny.

W postu na liście mailowej Junio C Hamano (opiekun Gita) podsumował, dlaczego uważa, że narzędzie do śledzenia błędów nie jest zbyt przydatne. Nie chcę dołączać całego postu (jest dość długi), ale sprowadza się do:

Jeśli szukasz tylko informacji o rozwiązanych problemach, przeszukiwanie archiwów list działa równie dobrze, jak przeszukiwanie modułu do śledzenia błędów.
Jeśli zgłosisz prawdziwy błąd, a ludzie chcą się tym zająć, lista również działa dobrze.
Jeśli nikt nie jest zainteresowany pracą nad problemem, wpadnie przez pęknięcia, nawet w narzędziu do śledzenia błędów.
Śledzenie błędów byłoby jeszcze jednym systemem, który należy utrzymywać, regularnie sprawdzać pod kątem nowych błędów, mieć zamknięte błędy itp., W skrócie, dodatkowa praca dla niewielkiej korzyści.

— Śleske
źródło

5

Dobra odpowiedź, ale twierdzę, że twój trzeci punkt jest główną wadą wiadomości e-mail: jeśli błąd jest trudny do naprawienia, a obecni deweloperzy są leniwi, staje się znacznie bardziej zakopany niż wpis w narzędziu do śledzenia problemów. Może to oznaczać, że niektóre błędy nigdy nie zostaną naprawione, po prostu dlatego, że ludzie ich nie znają

— TheLQ

1

@TheLQ: True. Jednak najwyraźniej jest to ryzyko, które niektóre projekty są skłonne podjąć. Szczerze mówiąc, git jest dość solidnym oprogramowaniem, nawet bez narzędzia do śledzenia błędów.

— śleske,

1

@TheLQ: Czy prosta strona internetowa zawierająca informacje o wszystkich znanych błędach (i powiązanych wątkach) nie rozwiązałaby tego? Coś podobnego do tego oprócz tego, że linki wskazują na wątki archiwalne.

— Hello World,

1

@HelloWorld: To byłby (prosty) moduł do śledzenia problemów. I podobnie jak narzędzie do śledzenia problemów, ktoś musiałby nim zarządzać ...

— sleske,

Czy istnieje jednak dobry sposób na uzyskanie kopii offline wiadomości e-mail, która została wysłana, gdy nie byłem subskrybentem?

— PSkocik

6

Debian używa narzędzia do śledzenia błędów, jego domyślnym interfejsem jest e-mail. I to jest wygodne. Lucas Nussbaum, obecny Lider Projektu Debian, napisał kilka dni temu :

debbugs to oprogramowanie stojące za systemem śledzenia błędów Debiana (BTS). Jest również wykorzystywany w projekcie GNU. Pomimo tego, że często jest postrzegany jako w starym stylu, posiada kilka unikalnych funkcji, takich jak śledzenie statusu błędów w każdej wersji i gałęzi pakietu) lub możliwość wykonywania wszystkich interakcji za pośrednictwem poczty elektronicznej, co bardzo ułatwia pracę offline lub w słabo połączonych środowiskach.

Ostatnia część to funkcja zabójcy - po prostu ustaw kolejkę raportów w lokalnej kolejce poczty, aż wysiądziesz z samolotu!

— Dominik George
źródło

4

Chroni 9-latków.
Nie trzeba tworzyć osobnego konta dla każdego forum.
[drobny] Konsekwentne wrażenia użytkownika na różnych listach mailowych i zerowa krzywa uczenia się podczas subskrybowania nowej listy.
Działa offline. możesz połączyć się z Internetem i pobrać partię maili, a następnie wybrać się na wędrówkę, napisać odpowiedzi, ciesząc się matką naturą, i wysłać je później.
Umożliwia szyfrowanie i / lub podpisywanie poczty przez GPG.
Zdecentralizowane - jeśli forum się zawiesi, nadal będziesz mieć kopię, jest ona również odporna na manipulacje, zły moderator / haker nie może łatwo manipulować tym, co powiedziałeś. Nikt nie może cofnąć historii.
Umożliwia filtry, foldery i wszystkie zaawansowane funkcje organizacyjne klienta poczty e-mail.
„Powiadomienia wypychane” - możesz pozostawić otwartego klienta poczty e-mail i otrzymywać powiadomienia o nowych odpowiedziach.
Jedno miejsce do rządzenia nimi wszystkimi - nie trzeba przeskakiwać między różnymi stronami.
Odporny na wszystkie luki bezpieczeństwa związane z siecią (html / javascript / injections itp.)
No bloat - Brak odznak, fantazyjnych ruchomych podpisów, reklam, sygnałów nawigacyjnych w sieci Web, wzdęcia javascript. Wszystko jest proste i do rzeczy - dyskusja.
Mniejsze obciążenie serwera niż konfiguracja LAMP.

Jedną z wad list dyskusyjnych, które przychodzą na myśl, jest to, że fora można podzielić na kategorie i podkategorie, podczas gdy listy dyskusyjne nie są. Można to emulować, dzieląc listę mailingową na kilka list mailingowych, a następnie użytkownicy mogą użyć odpowiednich filtrów, aby umieścić każdą wiadomość z odpowiadającym jej folderem (każdy folder jest kategorią). Na forach internetowych jest to automatyczne.

— Witaj świecie
źródło

dlaczego ludzie nalegają na tworzenie wersji internetowych w celu śledzenia problemów (BTW to pytanie nie dotyczy wszystkiego ) omówiono w innym pytaniu: Skłonienie użytkowników do napisania przyzwoitych i użytecznych raportów o błędach „Edytowane przez użytkownika raporty o błędach online są najskuteczniejszym sposobem nauczania Użytkownicy poprawiają ... ”

— komnata

Dziękuję Ci. Ale czy to uzasadnia opinię negatywną? Głównym tematem tej odpowiedzi są zalety ML i dość dobrze odpowiada na pierwotne pytanie. Usunąłem „fora internetowe”.

— Hello World,

2

Wada wymieniona w tej odpowiedzi zasadniczo uniemożliwia mi trzymanie się większości list deweloperów. Wysyłają wszystko , więc po zgłoszeniu błędu zwykle rezygnuję z subskrypcji zaledwie dwa tygodnie później. Bugtrackerzy ładnie rozwiązują ten problem, pozwalając mi zasubskrybować określone raporty błędów.

— Roman Starkov

6

Korekta: utrzymuje 25 -latków poza domem. Dopiero niedawno dowiedziałem się, jak te listy mailingowe działają, aby przyczynić się do niektórych prawdziwych projektów. I nienawidzę tego !!

— Ciro Santilli 31 改造中心法轮功六四事件

2

„Nie trzeba tworzyć osobnego konta dla każdego forum”. - często w celu uniknięcia spamu musisz zapisać się na listę. Ale to subskrybuje wszystkie e-maile. Musisz więc zasubskrybować ORAZ zrezygnować z „spamu” ORAZ dodać prośbę o pozostanie w CC lub TO. W porównaniu z Bugzillą jest o wiele więcej do zrobienia.

— Maciej Piechotka,