Bugzilla/Bug report guide/ko

모범 사례
요령: 버그 보고서를 쓸 때 삶의 단 한번의 기회가 주어졌음을 생각하는게 중요합니다. 수신자가 영문을 읽을 줄 안다는거 여러분도 압니다만, 주로 사용하는 언어는 아닙니다.
 * 제출 전에 다시 읽어주십시오. 바꾼 내용은 되돌릴 수 없고 제출한 다음에 다시 편집할 수 없습니다. 버그 보고서에 입력한 텍스트는 수많은 사람에게 즉시 전자메일로 발송합니다. 간명한 언어로 기술하고 대화체는 피해주십시오.


 * 버그 보고서를 꾸리기 전 중복 여부를 검색하십시오.


 * 항상 주제를 지키십시오 - 버그 추적 시스템은 기술적 보고서를 처리하는데 사용하며 잡담은 배제합니다. 지원 채널(포럼, IRC, 메일링 리스트)en 에서 이 점을 지켜주십시오.
 * 적어도 한번 문제가 있는지 확인하십시오 - 다른 사람이 또 보고하면 문제를 해결하는데 도움이 안됩니다. 허나 여러분이 보유한 시스템과 확인한 사람의 시스템이 명백히 다르거나 하여 알아야 할 사항이 있다면, 해당 정보를 추가하십시오
 * 하나의 주제에 하나의 버그를 다루십시오 - 보고한 버그 보고서에서 다루는 문제가 아니라면, 해당 문제를 찾거나 새 보고서를 작성하십시오. 다른 버그 내용을 갖아 붙여넣지 마십시오.
 * 추적기의 버그에 대해선 말하지 마십시오 - 해당 버그는 통상적인 버그입니다. 쓸만한 정보를 추가하려면 관련 하위 버그 보고서에 추가하든지 새 버그 보고서를 만드십시오.

꾸러미/이빌드
버그에 시스템 설정 정보를 항상 추가해야합니다. 이렇게 하려면 다음 내용을 새 첨부 파일로 만들어 붙여넣으십시오:

빌드 시간 버그 보고(이머지 실패)

 * First write the exact version of the package in the title of the bug report e.g. sys-apps/package-2.3-r4
 * Add a short description to the title.
 * Attach the logs to the bug ticket

실행 시간 버그 보고
파일 및 관심 정보는 우선 순위에 따라 정렬합니다:


 * sys-apps/package-2.3-r4 crashes with error: Cannot proceed...와 같은 버그 보고서의 제목에 명시한 정확한 버전
 * 다른 사람이 재현할 수 있도록 하는 문제 설명
 * 프로그램 실행 방법(콘솔, 터미널, 데몬, 어떤 런레벨인가 등)
 * 오류 출력
 * 프로그램이 깨졌을 때, 뭔가가 잘못됐을 때, 시작하지 않았을 때의 원인
 * 해결책이 있는가?
 * 꾸러미의 최신 동작 버전이 있다면 몇인가?
 * 동작하지 않게 하는 (바뀐) 원인이 무엇인가?
 * emerge --info 출력 결과 첨부
 * 의존 요소를 간단하게 확인하는데 필요한 emerge -pv  출력 결과 첨부

그 동안 업스트림에서 새 릴리즈가 나와 버전을 올려달라고 요청

 * Search Bugzilla before posting a bump request - is there already a bug open? Has the local Portage tree been synced lately; is it already in Portage?
 * Avoid zero-day bump requests (wait at least 48 hours after the release announcement)
 * Has it actually been released by upstream sources, or is it just marked in the source tree? Some projects mark a release in the tree long time before it is officially released.
 * Be sure to mention if it compiles and runs well on your arch. Any other helpful information you provide is most welcome.
 * Add a link to the upstream website
 * Give a link or list of fixed bugs or new features (sometimes called changelog)
 * Write a summary in the form app-editors/vim-12.3.5 version bump

추가 고려사항

 * 새 버전에서 이빌드 내용을 필요로 하지 않는다면, 알려주십시오
 * 첨부 파일을 제출하기 전에 로컬 오버레이에서 이빌드를 테스트하십시오
 * 바뀐 내용에 대한 설명을 곁들여 제안한 이빌드 편집의 패치를 제공하십시오(파일 이름은 이전 버전이 아닌 새 버전 번호에 맞춰야 합니다)
 * 추가 파일(initd, unit 파일)을 별도로 첨부(필요한 대로)로 제공하십시오
 * 답글에 이빌드 또는 이빌드 관련 내용을 직접 붙여넣지 마십시오. 이렇게 하려면 첨부하십시오.

새 꾸러미에 대한 이빌드 요청
포티지 트리에 추가할 프로그램의 새 이빌드를 요청하려면 꾸러미의 관리자를 찾거나 자신이 직접 꾸러미 관리자가 돼야합니다:


 * Link to the upstream website in the bug report
 * Give a link or list of features
 * Suggest a preliminary category and package name for the ebuild in the subject line for example media-gfx/inkscape ebuild request
 * Provide an ebuild and patches that were tested in your local overlay (you can get help in IRC or in the forums with that)

XY 꾸러미를 안정 버전으로 처리해야 함
비 안정버전 상태에서 30일 이상이 흘렀지만 여전히 불안정하다고 표시한 꾸러미를 빌드하고 문제없이 시스템에서 돌아가는 경우에 해당합니다:

커널
커널 버그 보고서의 파일과 관심 정보는 우선 순위에 따라 정렬합니다:


 * 사용하고 있는 커널 및 버전, 사용중인 아키텍처. x86_64의 gentoo-sources-3.4.2-r2
 * 커널 설정 파일을 버그 보고서에 첨부해야합니다
 * 시스템의 모든 장치 목록을 lspci -k로 가져올 수 있습니다
 * 커널 초기화시에 나오는 또는  로그 파일을 첨부해야합니다.

추가 참조

 * 버그질라 안내서en
 * 젠투에 기여하기en
 * 안정화 요청en
 * 젠투 GitHuben - 젠투 프로젝트를 돕고 GitHub에 풀 요청 보내기를 고려해보세요