Tại sao một số dự án lớn, như Git và Debian, chỉ sử dụng danh sách gửi thư mà không phải là trình theo dõi vấn đề?

Trình theo dõi lỗi cho bất kỳ dự án có kích thước phù hợp nào có vẻ như không có chút trí tuệ đối với tôi - nó giúp việc tổ chức hàng trăm hoặc hàng nghìn vấn đề thực sự dễ dàng, không có vấn đề va chạm hoặc bị lẫn lộn.

Vì vậy, khi tôi thấy một số dự án thực sự lớn, như Git, sử dụng danh sách gửi thư làm phương pháp chính để phối hợp bảo trì và phát triển, tôi đã bị thổi bay một chút. Ví dụ:

• Git - Trang cộng đồng :

  ... Báo cáo lỗi nên được gửi đến danh sách gửi thư này.

• Hệ thống theo dõi lỗi Debian , theo Wikipedia:

  ... Tính năng độc đáo của nó là nó không có bất kỳ hình thức giao diện web nào để chỉnh sửa các báo cáo lỗi - tất cả các sửa đổi được thực hiện thông qua email.

Nhiều trình theo dõi lỗi hiện đại có tích hợp rất tốt với email (bạn có thể nhận được nhận xét hoặc thông báo về các lỗi bạn đang xem hoặc được chỉ định cho bạn), cũng như các hệ thống kiểm soát phiên bản (cam kết có thể được đánh dấu là giải quyết vấn đề, v.v. .). Phần lớn việc này sẽ phải được thực hiện thủ công với danh sách gửi thư và bạn nhận được vô số email về các lỗi mà bạn không quan tâm.

Vì vậy, những lợi thế chính của danh sách gửi thư so với trình theo dõi lỗi dựa trên web là gì? Tại sao một số dự án lớn chỉ sử dụng một danh sách gửi thư?

Tùy chọn bạn quan sát có vẻ như là kết quả tự nhiên của khuyến nghị được nêu rõ trong Tiêu chuẩn mã hóa GNU . Nó gợi ý để báo cáo lỗi qua email, như bạn có thể thấy trong trích dẫn bên dưới (Tôi đã đánh dấu đậm phần trực tiếp giải quyết các quan sát của bạn):

4.7.2 --help

--helpTùy chọn tiêu chuẩn sẽ xuất tài liệu ngắn gọn về cách gọi chương trình, trên đầu ra tiêu chuẩn, sau đó thoát thành công. Các tùy chọn và đối số khác nên được bỏ qua một khi điều này được nhìn thấy và chương trình không nên thực hiện chức năng bình thường của nó.

Gần cuối ‘--help’đầu ra của tùy chọn, vui lòng đặt các dòng cung cấp địa chỉ email cho các báo cáo lỗi , trang chủ của gói (thông thường ‘http://www.gnu.org/software/pkg’và trang chung để được trợ giúp sử dụng các chương trình GNU. Định dạng phải như sau:

    Report bugs to: mailing-address
    pkg home page: <http://www.gnu.org/software/pkg/>
    General help using GNU software: <http://www.gnu.org/gethelp/>

Bạn có thể đề cập đến các danh sách gửi thư và trang web thích hợp khác.

Ngược lại, ưu tiên trên phản ánh sự chấp nhận phổ biến của email như một hình thức giao tiếp điện tử. Bất kỳ người dùng đọc --helptin nhắn như đề xuất ở trên được cho là dễ dàng hiểu phải làm gì nếu họ gặp lỗi - việc gửi thư rất dễ dàng.

Trình theo dõi vấn đề có thể (và tôi nghĩ là ) tốt hơn cho nhà phát triển làm việc trong dự án, nhưng đối với đối tượng rộng hơn sẽ khó trình bày và giải thích cách sử dụng nó, đặc biệt là tính đến sự đa dạng và khác biệt giữa các hệ thống theo dõi vấn đề khác nhau .

Một dự án có thể sử dụng Bugzilla, một dự án khác sẽ gắn bó với JIRA, thứ ba với ... GNATS , v.v., v.v. Không có cách nào để trình bày tất cả "sở thú" này theo cách chuẩn và thống nhất như

Report bugs to: mailing-address

Lưu ý ở trên không có nghĩa là các dự án không nên sử dụng theo dõi vấn đề trong nội bộ . Như đã giải thích trong một câu trả lời xuất sắc cho câu hỏi liên quan ,

Trình theo dõi lỗi của bạn là để thuận tiện cho bạn chứ không phải cho khách hàng của bạn. Nếu bạn không thể bận tâm đến vấn đề điện thoại hoặc email của họ và tự nhập nó, bạn nghĩ họ cảm thấy thế nào?

Bạn cần có thể nhập các vấn đề và gán chúng theo cách thủ công cho khách hàng ...

Cụ thể với Git, có một lý do lịch sử đơn giản: Git được bắt đầu bởi tin tặc Linux cho tin tặc Linux và nó sử dụng mô hình và công cụ phát triển giống như chính Linux. Tuy nhiên, Linux cũ hơn WWW, vì vậy, khi Linux được khởi động, đơn giản là không có trình theo dõi vấn đề dựa trên web, vì không có web!

Do đó, cộng đồng Linux đã phát triển các công cụ và quy trình làm việc cực kỳ hiệu quả để xử lý các báo cáo lỗi và đánh giá mã qua email, và không có lý do gì để họ vứt bỏ tất cả công việc đó và bắt đầu lại từ đầu khi họ bắt đầu dự án Git.

Đối với Git:

Có một số cuộc thảo luận trong danh sách gửi thư nơi mọi người đề xuất sử dụng một số loại trình theo dõi lỗi. Những sáng kiến ​​này dường như đã bị xì hơi, vì vậy lý do Git không sử dụng trình theo dõi lỗi có lẽ chỉ đơn giản là hầu hết những người đóng góp không thấy nó hữu ích.

Trong một bài đăng trên danh sách gửi thư , Junio ​​C Hamano (người bảo trì của Git) đã tóm tắt lý do tại sao anh ta cảm thấy trình theo dõi lỗi không hữu ích lắm. Tôi không muốn bao gồm toàn bộ bài viết (nó khá dài), nhưng nó sôi nổi lên:

• Nếu bạn chỉ tìm kiếm thông tin về các vấn đề đã được giải quyết, việc tìm kiếm tài liệu lưu trữ danh sách cũng hoạt động cũng như tìm kiếm trình theo dõi lỗi.
• Nếu bạn báo cáo một lỗi chính hãng và mọi người muốn chăm sóc nó, danh sách này cũng hoạt động tốt.
• Nếu không ai quan tâm đến việc xử lý một vấn đề, nó sẽ rơi vào các vết nứt, ngay cả trong một trình theo dõi lỗi.
• Trình theo dõi lỗi sẽ là một hệ thống nữa cần được bảo trì, kiểm tra các lỗi mới thường xuyên, đã sửa các lỗi đã được sửa, v.v., tóm lại, làm thêm để có ít lợi ích.

Debian không sử dụng trình theo dõi lỗi, giao diện mặc định của nó là email. Và nó là thuận tiện. Lucas Nussbaum, Trưởng dự án Debian hiện tại, đã đăng một vài ngày trước :

debbugs là phần mềm đằng sau Hệ thống theo dõi lỗi của Debian (BTS). Nó cũng được sử dụng bởi dự án GNU. Mặc dù thường được coi là kiểu cũ, nó có một số tính năng độc đáo, chẳng hạn như theo dõi trạng thái lỗi trong từng phiên bản và nhánh của gói) hoặc khả năng thực hiện tất cả các tương tác qua email, giúp thao tác rất dễ dàng ngoại tuyến hoặc trong môi trường kết nối kém.

Phần cuối cùng là một tính năng giết người ở đây - chỉ cần xếp hàng các báo cáo đó trong hàng đợi thư địa phương cho đến khi bạn xuống máy bay!

• Giữ trẻ 9 tuổi.
• Không cần phải tạo một tài khoản riêng cho mỗi diễn đàn.
• [nhỏ] Trải nghiệm người dùng nhất quán trên các danh sách gửi thư khác nhau và đường cong học tập bằng không khi đăng ký vào danh sách mới.
• Hoạt động ngoại tuyến. bạn có thể kết nối Internet và tải xuống một loạt thư, sau đó đi bộ đường dài, viết thư trả lời trong khi tận hưởng thiên nhiên của mẹ và gửi chúng sau.
• Cho phép mã hóa thư và / hoặc ký thông qua GPG.
• Phân cấp - Nếu diễn đàn gặp sự cố, bạn vẫn có một bản sao, nó cũng chống lại sự giả mạo, một người điều hành / hacker xấu xa không thể dễ dàng giả mạo những gì bạn đã nói. Không ai có thể hoàn tác lịch sử.
• Cho phép các bộ lọc, thư mục và tất cả các tính năng tổ chức nâng cao của ứng dụng Email.
• "Thông báo đẩy" - bạn có thể để ứng dụng Email của mình mở và nhận thông báo về các phản hồi mới.
• Một nơi để thống trị tất cả - không cần phải nhảy giữa các trang web khác nhau.
• Miễn nhiễm với tất cả các lỗ hổng bảo mật liên quan đến web (html / javascript / tiêm, v.v.)
• Không phình to - Không có huy hiệu, chữ ký di chuyển ưa thích, quảng cáo, đèn hiệu web, bloascript javascript. Tất cả đều đơn giản và đến mức - thảo luận.
• Ít gánh nặng máy chủ hơn thiết lập LAMP.

Một nhược điểm của danh sách gửi thư xuất hiện trong tâm trí là các diễn đàn được chia thành các danh mục và danh mục con trong khi danh sách gửi thư thì không. Điều này có thể được mô phỏng bằng cách chia danh sách gửi thư thành nhiều danh sách gửi thư và sau đó người dùng có thể sử dụng các bộ lọc phù hợp để đặt từng thư với thư mục tương ứng (Mỗi thư mục là một danh mục). Trong các diễn đàn web, điều này là tự động.