버그 수정 패치는 누구의 책임입니까?

오픈 소스 프로젝트에서 여러 번 발생한 상황은 다음과 같습니다.

1. 배포에서 버그를 발견하고 빠른 해킹 패치를 알아 냈습니다. 예를 들어 실제로 필요하지 않은 코드를 주석 처리하면됩니다.
2. 나는 실제 버그를 알아 내고 패치를 만들어 Git pull request 등을 통해 제출하기 위해 약간의 노력을 기울였다.
3. 풀 요청이 거부되었습니다. 아마도 패치가 불완전했을 것입니다 (예를 들어, 가지고 있지 않은 라인 포함), 아마도 코딩 스타일을 위반했을 것입니다. 아마도 다른 결과가있을 수 있습니다. 또는 Git에서 뭔가 잘못했을 수도 있습니다. 풀 요청이 다시 기반이 되었어야합니다. 관리자는 패치를 개선하는 방법에 대한 피드백을 제공하고 다시 제출하도록 요청합니다.

이 시점에서 나는 얼마나 멀리 진행해야하는지 혼란스러워합니다. 걱정되는 한 문제가 없습니다. 1 단계에서 문제를 해결했습니다. 문제를보고했으며 다른 사람들을 위해 문제를 해결하기위한 조치도 취했습니다. 그러나 나는 그것이 "나의"풀 요청이라고 생각하지 않기 때문에 패치 개선에 대한 책임이 나에게 온다고 생각하지 않는다.

패치에 실패한 것에 대한 토론을 한 후, 우리는 올바른 패치가 무엇인지 (즉, 철자가 모든 코드 라인을 포함하여 어떻게 동작해야하는지) 메일 링리스트에 동의합니다. 그런 다음 패치를 실제로 생성하여 제출하는 것은 여전히 ​​본인의 책임입니다.

이러한 상황에서 표준 에티켓이 있습니까? 그들은 어떻게 해결됩니까? 내 반응이 특이합니까? 버그 수정을 받기까지 얼마나 걸립니까?

(내가 "오픈 소스 프로젝트"라고 말하면, 이들 중 일부는 매우 작지만 취미가 아닐 수 있습니다. 단순히 여러 조직에서 사용하는 소규모 소프트웨어 프로젝트로, 개발자 리소스를 사용하여 작업하는 개발자가 될 것입니다. "패치 수정 및 다시 제출"입니다. 고용주에게 도움이되는 작업을 수행해야 할 책임이 있음을 이해합니다. 우리에게 영향을 미치지 않는 버그를 수정하는 데 시간이 걸리는 것은 잘못된 것입니다 ...)

내가 우려하는 한, 버그를 발견하거나 개선 요청을 받았거나 프로젝트에 기여한 사람이 아니며 적절한 채널을 통해 결함 보고서를 제출하면 완료됩니다. 커뮤니티에 환원하는 것과 관련하여 오픈 소스 프로젝트를 사용하고 결함을 발견 한 사람은이를보고해야합니다.

솔루션을 찾고, 디자인하고, 구현하는 것은 프로젝트에 대한 보너스입니다. 이 작업을 수행 한 경우 풀 요청을 통해 또는 결함 보고서 또는 개선 요청과 함께 파일 델타를 개발 팀에 전송하여 작업 할 무언가를 제공하는 것이 좋습니다. 그러나 프로젝트에 대한 귀하의 기여를 수락 할 의무는 없습니다.

사용자가 패치를 제공 할 것을 기대하는 것은 나에게 잘못된 것 같습니다. 문제에 대한 토론에 참여하는 것은 상당히 쉽지만 해결책을 찾는 데 훨씬 많은 시간이 소요됩니다. 어떤 프로젝트도 비기 여자가 단일 문제를 해결하기 위해 기고자가 될 것으로 기 대해서는 안됩니다.

당신이 그것을 참을 수있는 한 진행하십시오. 패치를 수정하여 메인 트렁크의 세계와 공유하는 것이 좋겠지 만, 관리자가 원하지 않으면 어깨를 으.하십시오. 문제가있는 어딘가에 게시하고 문제를 해결하기 위해 패치를 작성하여 같은 보트에있는 다른 사람들이 솔루션을 검색 할 수 있습니다.

그리고 당신은 문제가 없습니다. 패치는 다음 업그레이드에 포함되지 않습니다. 따라서 새로운 버전을 얻을 때마다 다시 패치해야하며 제대로 작동하거나 마사지해야합니다. 따라서 주요 프로젝트에 들어가면 장기적으로 시간을 절약 할 수 있습니다.

그것은 당신에게 고통이지만, 당신은 지역 사회에 기여하고 있습니다. 모든 기여자들이 고맙게 생각합니다. 그것은 대중에서 마술처럼 창시 된 고급 소프트웨어와는 다릅니다. 누군가는 일을해야합니다. (그래서 누가 대단해? 넌 대단해). 마음에 들지 않으면 어떻게해야하는지에 대한 토론에 감사하지만, 너무 바쁘다는 것을 커뮤니티에 알리십시오. 그들은 무엇을 할 것인가? 임금을 삭감 하시겠습니까?

오픈 소스 문화를 이해하기 쉽게 만드는 하나의 교리가 있습니다. 작업을 수행하는 사람이 무엇을해야할지 결정합니다. 이것은 개발자의 주간 직업과 비교할 때 그 매력 중 하나입니다. # 1 우선 순위는 백 로그에서 # 50 일 수 있습니다. 풀 요청을 수정하지 않으면 결국 맨 위로 이동하여 처리합니다. 그러나 당신이 그들을 위해 충분히 쉽게 만들면, 그들은 지금 그것을 돌볼 것입니다.

풀 요청을 수정하도록 요청하는 다른 이유는 더 웅장합니다. 그들은 당신이 작게 기여한 것에 대한 크레딧을 얻기를 원합니다. 수정을 수행하면 커밋의 작성자 필드에 이름이 있습니다. 대부분의 사람들은 그것을보고 싶어하는 그들의 공헌에 대해 자부심을 가지고 있으므로, 관리자의 기본 방식은 그들에게 맡기는 것입니다.

고용주에 대한 귀하의 책임 인 한, 귀하의 사업체가이 규범에 의존하는 경우, 귀하는 그러한 행동을하지 않습니다. 고용주는 노동자가 도구를 연마하는 데 시간이 걸리는 이점을 알고 있습니다.

오픈 소스 방식 인 AFAIK는 버그를 수정하는 책임을지는 버그를 충분히 처리하는 사람이 버그를 수정하는 책임을진다는 것입니다. 상황에 따라 문제를 무시하는 것부터 문제를 해결하는 것 (패치 제공 및 수용되도록 논쟁)에 이르기까지 모든 문제를 해결했습니다.

모든 것이 옳습니다. 프로젝트를 관리하는 사람들이 당신에게서 잘못된 것을 기대하지 못하게하십시오 (즉, 토론 옵션으로 문제를 올바르게 해결하고 아무것도하지 않기를 바랍니다). 아마도 더 많은 문제를 알고 있습니다. 자신을 다룰 수 있고 가능하다면 반복적으로 기여할 것입니다.

원래 버그는 나에게만 영향을 줄 수 있으므로 패치를 준수하는 데 필요한 모든 작업을 수행하여 제출을 얻는 것이 매우 중요합니다. 그렇지 않으면 다음 수정 버전 (다른 수정 프로그램이 필요하기 때문에)에 수정 프로그램이 없습니다.

프로젝트의 새 복사본을 가져올 때마다 적용해야하는 패치 목록을 유지하고 싶지 않습니다. 너무 많은 문제 일뿐입니다. 약간의 시간이 더 걸리고 영구적으로 고정되므로 다시 처리 할 필요가 없습니다.

오픈 소스 개발자에게는 두 가지 유형의 문제가 있습니다.

• (a) 패치가없는 문제
• (b) 패치로 인한 문제

필자는 대부분의 오픈 소스 패키지 관리자 / 개발자가 비 핵심 사용자를 패치로 빠르게 처리 할 수있는 아이디어를 좋아한다고 생각합니다.

그러나 이들의 주요 목표는 b 형 문제의 수를 최소화하는 것입니다. 그 때문에 바가 꽤 높게 설정됩니다.

어떤 사람들은 그것을 능가합니다. 이들은 기고자 또는 핵심 기고자 일 수 있습니다. 다른 사람들은 포기합니다. 오픈 소스에는 특정 다윈의 성격이 있습니다.

팀이 그것을 받아들이는 지점에 당신의 공헌을 눌렀고 뱉어내는 것이 좋습니다. 당신이 몇 가지 공헌을 한 후에는, 그들은 당신을 더 신뢰하지만, 당신의 공헌이 완벽한 지 확인해야합니다.

최종 결과는 그만한 가치가 있습니다. "코드를 작성합니까? 예 ... 매일 쓴 것을 실행하고 있습니다."