Git 및 Debian과 같은 일부 큰 프로젝트가 이슈 트래커가 아닌 메일 링리스트 만 사용하는 이유는 무엇입니까?

괜찮은 규모의 프로젝트에 대한 버그 추적기는 나에게는 쉬운 일이 아닙니다. 충돌이나 혼동되는 문제없이 수백 또는 수천 개의 문제를 쉽게 구성 할 수 있습니다.

따라서 Git과 같은 정말 큰 프로젝트를 보시면 메일 링리스트를 유지 보수 및 개발을 조정하는 주요 방법으로 사용하면 조금 혼란스러워집니다. 예 :

• 힘내-커뮤니티 페이지 :

  ... 버그 보고서는이 메일 링리스트로 보내 져야합니다.

• 위키 백과에 따른 데비안 버그 추적 시스템 :

  ... 독특한 기능은 버그 보고서를 편집 할 수있는 웹 인터페이스가 없다는 것입니다. 모든 수정은 이메일을 통해 이루어집니다.

많은 최신 버그 추적기는 전자 메일 (보고있는 버그 또는 할당 된 버그에 대한 의견이나 알림을받을 수 있음)과 버전 제어 시스템 (커밋이 문제를 해결하는 것으로 표시 될 수 있음 등)과 매우 잘 통합되어 있습니다. ). 이 중 대부분은 메일 링리스트를 사용하여 수동으로 수행해야하며 관심이없는 버그에 대한 많은 이메일을받습니다.

그렇다면 웹 기반 버그 추적기보다 메일 링리스트의 주요 장점은 무엇입니까? 일부 큰 프로젝트는 메일 링리스트 만 사용하는 이유는 무엇입니까?

당신이 관찰 한 선호도는 GNU 코딩 표준 에 명확하게 언급 된 권고의 자연스러운 결과처럼 보입니다 . 아래 인용에서 볼 수 있듯이 전자 메일로 버그를보고하는 것이 좋습니다 (관심 사항 을 직접 다루는 부분 은 굵게 표시되어 있음).

4.7.2 --help

표준 --help옵션은 표준 출력에서 ​​프로그램을 호출하고 성공적으로 종료하는 방법에 대한 간단한 문서를 출력해야합니다. 이 옵션이 표시되면 다른 옵션과 인수는 무시해야하며 프로그램은 정상적인 기능을 수행하지 않아야합니다.

‘--help’옵션 출력 이 끝나는 시점에서 버그 보고서 , 패키지의 홈 페이지 (일반적으로 ‘http://www.gnu.org/software/pkg’, GNU 프로그램 사용에 대한 일반 페이지) 의 전자 메일 주소를 제공하는 행을 배치 하십시오 . 형식은 다음과 같아야합니다.

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

다른 적절한 메일 링리스트와 웹 페이지를 언급해도 좋습니다.

상기 선호도는 전자 통신의 형태로서 이메일의 보편적 수용을 반영한다. --help위에서 제안한 메시지를 읽는 모든 사용자 는 버그를 발견하면 어떻게해야하는지 쉽게 이해할 수 있어야합니다. 메일 링은 쉽습니다.

이슈 트래커는 다음과 같을 수 있습니다 (그리고 내 생각 이다 ) 프로젝트에서 작업하는 개발자를위한 더 나은,하지만 더 넓은 청중을 위해 존재하고, 특히 계정 다양한 고려와 다른 차이, 그것을 사용하는 방법을 설명하기 어렵게 될 것이다 문제 추적 시스템 .

하나의 프로젝트는 Bugzilla를 사용할 수 있고, 다른 하나는 JIRA를 고수하고, 세 번째는 GNATS 등을 포함 할 것입니다.

Report bugs to: mailing-address

위의 참고는 프로젝트가 이슈 트래커를 내부적 으로 사용해서는 안된다는 의미는 아닙니다 . 에서 설명하고있는 바와 같이 관련 질문에 훌륭한 대답은 ,

버그 추적기는 고객이 아닌 편의를 위한 것 입니다. 전화 나 이메일로 문제를 겪지 않고 직접 입력 할 수 없다면 어떻게 생각하십니까?

이슈를 입력하고 클라이언트에 수동으로 할당 할 수 있어야합니다 ...

특히 Git을 사용하면 간단한 역사적인 이유가 있습니다. Git은 Linux 해커를위한 Linux 해커가 시작했으며 Linux와 동일한 개발 모델과 도구를 사용합니다. 그러나 Linux는 WWW보다 오래되었으므로 Linux가 시작될 때 웹 이 없었기 때문에 웹 기반 이슈 트래커 가 없었습니다 !

결과적으로 Linux 커뮤니티는 이메일을 통해 버그 보고서 및 코드 검토를 처리 할 수있는 매우 효율적인 도구와 워크 플로우를 개발했으며, Git 프로젝트를 시작할 때 모든 작업을 버리고 처음부터 다시 시작할 이유가 없었습니다.

힘내 :

사람들이 어떤 종류의 버그 추적기를 사용할 것을 제안하는 메일 링리스트에 관한 몇 가지 토론이 있습니다. 이러한 이니셔티브는 모두 어리석은 것처럼 보이므로 Git이 버그 추적기를 사용하지 않는 이유는 아마도 대부분의 기여자가 유용하지 않다는 것입니다.

A의 메일 링리스트에 포스트 그가 버그 추적기가 매우 유용하지 않습니다 느끼는 이유, Junio C 하마노 (망할 놈의 메인테이너는) 요약. 전체 게시물 (포함되지 않음)을 포함하고 싶지 않지만 다음과 같이 요약됩니다.

• 해결 된 문제에 대한 정보 만 찾으려면 목록 아카이브를 검색하고 버그 추적기를 검색하면됩니다.
• 당신이 진짜 버그를보고하고 사람들이 그것을 돌보고 싶어한다면,리스트도 잘 작동합니다.
• 아무도 문제에 관심이 없다면 버그 추적기에서도 균열을 겪을 것입니다.
• 버그 트래커는 유지 보수가 필요하고 정기적으로 새로운 버그가 있는지 확인하고 버그를 수정 한 등의 이점이 거의없는 추가 작업을 수행해야하는 하나 이상의 시스템입니다.

데비안은 버그 추적기를 사용하며 기본 인터페이스는 이메일입니다. 그리고 편리합니다. 현재 데비안 프로젝트 리더 인 Lucas Nussbaum 은 며칠 전에 게시했습니다 .

debbugs는 데비안 버그 추적 시스템 (BTS) 뒤에있는 소프트웨어입니다. GNU 프로젝트에서도 사용됩니다. 구식으로 인식되는 경우가 많지만 각 버전의 버그 상태 및 패키지 분기와 같은 몇 가지 고유 한 기능이나 전자 메일을 통해 모든 상호 작용을 수행하는 기능으로 작업하기가 매우 쉽습니다. 오프라인 또는 연결이 잘못된 환경

마지막 부분은 여기서 살인자 기능입니다. 비행기에서 내릴 때까지 해당 보고서를 로컬 메일 대기열에 대기하십시오!

• 9 살짜리를 유지합니다.
• 각 포럼마다 별도의 계정을 만들 필요가 없습니다.
• [사소한] 다른 메일 링 목록에서 일관된 사용자 경험과 새로운 목록에 가입 할 때 학습 곡선이 없습니다.
• 오프라인에서 작동합니다. 인터넷에 연결하여 메일 묶음을 다운로드 한 다음 하이킹을하고, 대자연을 즐기면서 답장을 작성하고 나중에 보낼 수 있습니다.
• GPG를 통한 메일 암호화 및 / 또는 서명을 허용합니다.
• 탈 중앙화-포럼이 충돌하더라도 여전히 사본을 보유하고 있으며, 변조 방지 기능이 있으며 악의 중재자 / 해커가 말한 내용을 쉽게 조작 할 수 없습니다. 아무도 역사를 취소 할 수 없습니다.
• 이메일 클라이언트의 필터, 폴더 및 모든 고급 조직 기능을 허용합니다.
• "푸시 알림"-이메일 클라이언트를 열어두고 새 회신에 대한 알림을받을 수 있습니다.
• 한곳에서 모두 다룰 수 있습니다. 다른 사이트 사이를 이동할 필요가 없습니다.
• 웹과 관련된 모든 보안 취약점 (html / javascript / injections 등)에 영향을받지 않습니다.
• 부풀림 없음-배지, 멋진 움직이는 서명, 광고, 웹 비콘, 자바 스크립트 부풀림 없음. 그것은 모두 간단하고 요점-토론입니다.
• LAMP 설정보다 서버 부담이 적습니다.

메일 링리스트의 한 가지 단점은 메일 링리스트는 그렇지 않지만 포럼은 카테고리와 하위 카테고리로 나눌 수 있다는 것입니다. 이것은 메일 링리스트를 여러 메일 링리스트로 나누어서 에뮬레이트 할 수 있으며, 사용자는 적절한 필터를 사용하여 각 메시지를 해당 폴더 (각 폴더는 카테고리)와 함께 넣을 수 있습니다. 웹 포럼에서 이것은 자동입니다.