버그 팁
이전
다음

버그 팁

적절한 소스 패키지

버그를 패키지에 지정하는 것은 도움이 가능한 개발자에게 버그 리포트를 가리키는 것을 돕습니다. 이 정보가 정확한 것을 확신하는 것으로, 여러분은 즉시 버그가 고쳐질 수 있는 기회를 높이게 됩니다. 자주, 어느 패키지가 버그를 가지고 있는지가 불분명하고, 이런 경우는 Ubuntu(역주: 특정 소스 패키지의 지정이 어려울 때 사용할 수 있음)로 버그를 파일하는 것이 적당 합니다. 만약 버그에 지정된 패키지가 확실히 틀렸거나, 올바른 패키지를 모른다면, 패키지를 Ubuntu로 변경 하십시오.

리눅스 커널 내의 버그를 위한 올바른 패키지는, 사용하는 (리눅스 커널을 포함하는 많은 패키지가 있습니다) 특정 패키지와 관계없이 linux 입니다.

문제 확인 하기

만약 버그가 Unconfirmed 로 표시되어 있다면, 여러분이 문제를 재현하는 것을 시도하고 그 결과를 Malone에 기록하는 것이 도움이 됩니다. 만약 문제를 확인할 수 있다면, 그 버그의 상태를 Confirmed 로 변경 하십시오. 문제를 확인하는 것이 불가능 하다면, 덧글로 그것을 기록하는 것도 역시 유용한 정보가 됩니다.

업스트림으로 버그 전달 하기

여러분은 다음의 경우, 소프트웨어 (업스트림)의 저작자에게 버그를 전달할 수 있습니다

  • 버그가 우분투 관련 변경에 의해 일어나지 않았음을 확신하였을 경우

  • 여러분과 팀의 다른 사람이 버그를 고치는 변경을 하는 것이 너무 어려울 경우

버그를 전달하는 경우, 다음과 같은 모든 필요한 정보를 포함하는 것을 확신 하십시오

  • 어떻게 버그를 재현 하는지

  • 어느 버전이 사용 되었는지 (만약 버그의 문제가 의존된 라이브러리에 있다면 그 버전)

  • 누가 버그를 리포트 하였는지

  • 어디서 전체 대화를 찾을 수 있는지

또한 이 버그를 위해 Malone의 버그 감시를 만드는 것을 확신 하십시오.

기능 요청 처리 하기

만약 여러분이 어느 보고된 버그가 기능 요청을 버그 리포트로 꾸몄다고 느낀다면, 보고자에게 우리가 가진 명세서 절차를 친절하게 소개 하십시오. 다음의 명세서 자원을 언급하는 것을 확신 하십시오: FeatureSpecifications, SpecSpec, SpecTemplate, 그리고 http://launchpad.net/specs

지원 요청 처리 하기

만약 여러분이 어느 보고된 버그가 지원 요청을 버그 리포트로 꾸몄다고 느낀다면, 보고자에게 우리가 가진 지원 추적을 친절하게 소개 하십시오. http://launchpad.net/support 를 언급하는 것을 확신 하십시오.

기본 설정을 변경하는 제안을 처리 하기

만약 여러분이 어느 보고된 버그가 기본 설정을 변경하는 제안을 버그 리포트로 꾸몄다고 느낀다면, 친절하게 그 논의를 적절한 메일링 리스트 또는 토론 포럼으로 돌리십시오. 그 변경이 이미 논의되었고 거부되었다면, 그 사용자에게 사유를 설명하고 더 이상의 제안과 의견을 위한 타당한 논의를 가리켜 주십시오.

중복된 버그 찾기

중복된 버그를 찾는 것은 버그 커뮤니티에서 매우 가치있는 기여 입니다. 사용자들은 때로 이미 파일된 같은 버그가 있는지를 어떻게 검사하는지 모르고, 상관하지 않습니다. 간단한 ME TOO 메세지를 제거하고 정보를 집합하는 것은 버그를 고치는 과정에 매우 중요 합니다.

이 측면에 여러분이 도움을 가질 수 있는 아주 약간의 수단이 있습니다. 하나는 같은 구성 요소 (역주: 소스패키지와 관련 라이브러리등) 의 파일된 버그를 찾는 것 입니다. 또한 여러분의 검색을 고쳐서 시도해 보고, 버그를 재현하는데 관계된 아이템을 기술하는 행위와 단어에 집중 합니다.

예:

만약 여러분이 그것을 오픈된 버그의 목록에서 찾을 수 없다면, 종료된 것의 목록에서 찾기를 시도할 수도 있습니다. 시작하면서 빨리 중복된 것을 찾을 수 없다고 해도 의욕 상실을 느끼지 마십시오. 얼마간의 시간이 흐른 후에, 여러분은 보통의 의심되는 것을 인식하고 그것들을 보다 쉽게 구별할 수 있게 됩니다.

참고

만약 여러분이 어느 버그가 형편없는/이해할 수 없는 제목을 가지고 있는 것을 보게 되면, 그것을 바꾸고 그러면 사람들이 보다 빨리 버그를 찾습니다.

Code of Conduct를 알려 주기

Code of Conduct는 버그 리포트의 대화에도 적용이 되는 것을 주의 하십시오. 만약 사람들이 공경치 않음을 관찰하게 된다면, 그들에게 우분투 Code of Conduct 를 가리켜 주십시오.

상태 관리 하기

버그 보고자로써 여러분은 보통 버그의 상태를 돌봐야 하지 않습니다. 버그 선별자 또는 개발자로써 버그를 분류하고 패키지와 소프트웨어의 상태에 대한 충분한 개략을 가지는데, 그것(상태)은 중요한 도구 입니다.

여러 가지 상태에 대한 간략한 목록과 설명이 여기 있습니다:

  • Unconfirmed: 버그는 이 상태에서 시작을 합니다. Unconfirmed 으로 표시는 버그는 때로는 부족한 정보, 준비가 안된 또는 확인이 안된 것 입니다. 그 버그 중의 대부분은 아직 선별되지 않았습니다.

  • Needs Info: 만약 여러분이 버그 보고자에게 물어볼 질문이 있다면, 그 버그를 "Needs Info" 로 정하십시오. Needs Info 버그의 보통 일은 역으로 물어보는 것 입니다. 적당한 기간이 지난 후에도 만약 대답이 없다면, 그 버그를 "If you have more information on this bug, please reopen." 라고 이야기 하며 닫으십시오.

  • Rejected: Rejected 로 표시된 버그는 종료된 것 입니다. 버그를 거절하기 전에 세 번 점검하는 것을 확신 하십시오.

  • Confirmed: 확인된 버그는 버그 버고자가 아닌 타인의 확인이 필요 합니다. 여러분 자신의 버그를 확인하지 마십시오.

  • In Progress: 만약 여러분이 버그를 고치는 작업을 시작하면, 버그의 상태를 In Progress 로 정하십시오. 그래서 사람들은 누군가 그 버그에 대한 작업을 하는 것을 알게 됩니다.

  • Fix Committed: 이 상태는 픽스가 업스트림의 CVS/SVN/bzr 또는 다른 곳에 커밋되었음을 의미 합니다. 패키지 관리자에게 이것은 변경은 잠시 멈춰있고 조만간 업로드 될 것이라는 것을 의미 합니다. (이것은 버그질라의 PENDINGUPLOAD 입니다.)

  • Fix Released: 업스트림 프로젝트를 위해 이것은 릴리스 tarball이 발표되었고 공개적으로 사용이 가능함을 의미 합니다. 패키지 관리자에게 이것은 픽스가 업로드 되었음을 의미 합니다. 덧글로 changelog 를 추가하는 것에 주저하지 마시고, 그래야 사람들이 그들의 버그에 어떤 변경이 영향을 주었는지 알 수 있습니다.

심각도 관리 하기

우분투는 심각도를 지정하는데 다음의 지침을 사용 합니다.

  • Wishlist: 우분투 내의 프로그램에 새 기능을 추가하는 요청. 이것은 버그가 정말로 버그가 아니라 아직 있지 않는 새 기능을 위한 아이디어일 때 사용 합니다.

  • Minor: 버그가 기능성에 나쁜 영향을 주지만, 대부분의 버그보다 범위가 적은 때 사용 합니다.

  • Normal: 일반적 종류의 기능성 버그 입니다. 대부분의 버그는 "Normal" 심각도 입니다.

  • Major: 버그가 우분투 사용자의 작은 부분에 (추정) 심각한 영향을 주거나 우분투 사용자의 큰 부분에 (추정) 적당한 영향을 가진 때 사용 합니다.

  • Critical: 버그가 우분투 사용자의 큰 부분에 심각한 영향을 가지고 있을 때 사용 합니다.

타켓 마일스톤

개발자에게 특별히 지시받지 않는 한 이 필드를 변경하지 마십시오. 특히, 이 필드를 어느 버그를 관찰했는지 우분투의 릴리스를 기록하기 위해 사용하지 마십시오: 그것은 이 필드의 용도가 아닙니다! 이것은 릴리스 팀이 특정 마일스톤 릴리스에 그 버그를 알리는 사유가 있을 때 사용 됩니다.

이전
다음
처음으로