버그가 최신 버전의 패키지(베타 또는 불안정)에서 수정된 경우 다음 주요 버전이 출시되기 전에 안정화될 수 있는 희망이 있습니까? 심각한 정도나 그와 유사한 경우가 아니면 그렇지 않을 것 같습니다.
실제로 2년 또는 3년 더 최신 버전을 작업하는 개발자에게 도움이 됩니까? 버그 보고에 최대한 많은 도움을 드리고 싶고, 이를 위해 가상 머신에 Sid 설치를 설정하여 안정적인 버전의 버그를 보고하기 전에 재현을 시도할 수 있지만 버그가 여전히 존재하더라도 새 버전에서는 개발자가 실제로 Stable에 대해 보고된 버그에 많은 주의를 기울이나요?
이 문제와 관련하여 말로 표현할 수 없는 추가적이고 모호한 질문이 많이 있다고 생각합니다. 하지만 기본적으로 일부 개발자를 괴롭히거나 오래된 패키지에 대해 보고할 수 있다면 의견을 듣고 싶습니다. 오류가 실제로 도움이 됩니다.
답변1
먼저 명확히 하자면, 릴리스(바이너리) 패키지와 원본 소스 패키지 사이에는 차이가 있습니다. 비록 일부디스트로테스팅, 불안정, 안정 등으로 저장소를 분리합니다.개발자또한 "stable", "unstable", "nightly" 및 기타 버전을 유지합니다.이것들은 다르다(그러나 버전 번호는 일치합니다).
또한 여기서 "소스 패키지"는 배포 패키지를 의미하지 않습니다 -src. 배포판과 독립적으로 배포되는 원본 소스를 의미합니다. 즉, 이는 일반적으로 직접 사용하지 않는 패키지입니다. 배포판에서는 이 패키지를 바이너리(및 -src) 형식으로 다시 패키지합니다.
예를 들어, 나는 foobar; 현재 안정적인 소스코드 패키지는 이고 1.2.4, 현재 불안정한 소스코드 패키지는 입니다 1.2.5. (제가 아닌) 데비안은 이것을 배포용으로 패키징합니다. 현재 안정적인 저장소는 이고 1.2.3, 현재 테스트 저장소는 입니다 1.2.5. 나 (원래 개발자)아니요 데비안 패키지 또는 어떤 소스 버전이 어떤 repo 패키지에 있는지를 담당합니다. 나는 배포용 바이너리 버전을 컴파일하거나 패키지화하지 않습니다. 그냥 원본 소스를 유지하고 있어요.
이러한 오류 보고서도 별개입니다. 나는 원 개발자로서 릴리스 패키지에 보고된 버그를 읽고 응답할 수도 있고 응답하지 않을 수도 있습니다. 그렇지 않은 경우 문제에 주의를 기울여야 하며 배포 포장업체에서는 원본 소스에 대한 보고서를 제출합니다.
버그가 최신 버전의 패키지(베타 또는 불안정)에서 수정된 경우 다음 주요 버전이 출시되기 전에 안정화될 수 있는 희망이 있습니까?
수정 사항은 백포트되는 경우가 거의 없습니다. 즉, 안정 릴리스 패키지가 1.2.3이고 1.2.5에 대한 수정 사항이 있다는 것을 알고 있는 경우 다음 안정 릴리스가 1.2.5 복구가 아니면 해당 수정 사항이 포함되지 않습니다. 즉, 배포판이 다음 안정 버전으로 1.2.4를 릴리스하는 경우 1.2.5의 수정 사항은 배포판으로 백포트되지 않으므로 버그는 여전히 존재합니다.
소스 코드와 관련된 버그(바이너리 패키지에 대한 WRT, 때로는 그렇지 않을 수도 있음)는 원래 개발자가 새 버전의 소스 코드를 수정한 다음 이를 릴리스 패키지의 해당 버전에 병합해야 합니다. 배포판에서 자체적으로 패치를 하고 버전에 접미사를 추가하여 표시하는 경우가 있기 때문에 몇 가지 예외가 있지만(예: 1.2.4-1) 소스의 후속 버전에 수정 사항이 있는 경우에는 그렇지 않다고 생각합니다.
실제로 2년 또는 3년 더 최신 버전을 작업하는 개발자에게 도움이 됩니까?
이는 버그 수정 여부에 따라 다릅니다. 버전 관리의 요점은 고정되어 있다는 것입니다. 일단 버전 1.2.3이 출시되면 무슨 일이 있어도 변경할 수 없습니다. 1.2.3에서 문제를 수정하면 다음 버전에 수정 사항이 표시됩니다. 수년 동안 중단된 경우 버전은 아마도 1.2.6 등일 것입니다.
따라서 최신 버전의 소스 코드에서 수정된 사항을 알고 있다면 이를 원래 개발자에게 보고할 필요가 없습니다. 하지만,현재 배포판에서 사용하는 안정적인 버전이고 버그가 아직 보고되지 않은 경우(소스와 패키지에 대해 보고된 버그가 다르다는 점을 기억하세요), 이를 보고하고 이후 버전의 버그가 보고되었음을 표시해야 합니다. 원천. 다시 한번 말하지만, 배포 패키지와 버그 보고서를 담당하는 사람은 원래 개발자와 다르다는 점을 명심하세요. 따라서 제가 문제를 해결하더라도 배포판 포장업체에서는 이를 모르거나 신경 쓰지 않을 수도 있습니다. 문제를 보고하면 계속해서 정보를 얻을 수 있지만그들에게 줘(저는 아닙니다), 당신은 분명히 그들의 관심을 끌었습니다. 이는 그들이 안정적인 패키지를 업그레이드하도록 장려할 수 있습니다(다른 배포판은 이에 대해 다른 기준을 사용합니다).
답변2
첫째, 버그 보고는 일반적으로 좋은 생각입니다. 비록 그것이 자유 소프트웨어의 많은 일처럼 고마운 일이기는 하지만 말입니다.
질문하신 내용을 순서대로 답변해드리자면,
버그가 최신 버전의 패키지(베타 또는 불안정)에서 수정된 경우 다음 주요 버전이 출시되기 전에 안정화될 수 있는 희망이 있습니까?
아마도 그렇지 않을 것입니다. 일반적으로 수정 사항은 보안 목적으로만 안정적인 릴리스로 백포트됩니다.
실제로 2년 또는 3년 더 최신 버전을 작업하는 개발자에게 도움이 됩니까?
안정적인 버전에서 버그를 발견한 경우 가장 먼저 해야 할 일은 현재 버전의 소프트웨어 또는 최소한 최신 버전에서 버그를 재현해 보는 것입니다. 일반적으로 이는 불안정한 릴리스에서 사용할 수 있으므로 불안정한 버전을 안정적인 버전으로 백포트하거나 불안정한 시스템에서 테스트할 수 있습니다. 불안정한 빌드에서 버그가 재현될 수 있다면 나는 보통 프로젝트 메일링 리스트에 다른 사람들이 버그를 재현할 수 있는지 물어봅니다. 때로는 버그만 보고하기도 합니다.
불안정한 버전이 최신 버전이더라도 개발 버전에서는 버그가 수정될 수 있으므로 현재 개발 버전의 소프트웨어(보통 소프트웨어 저장소에서만 사용 가능)를 테스트하지 않는 한, 이 버그는 아직 수정되지 않았는지 확인하세요. 그러나 나는 완전히 최첨단 코드를 테스트하는 데 신경 쓰지 않는 경우가 많습니다. 부분적으로는 코드가 아직 패키지화되지 않았기 때문이며, 패키지된 소프트웨어를 사용하는 것을 선호합니다. 하지만 YMMV.
최신 버전의 소프트웨어에서 버그가 수정된 경우 일반적으로 이를 보고하지 않습니다. 이론적으로는 이것이 가능하지만 업스트림 개발자는 확실히 신경 쓰지 않을 것이며 AMD 소프트웨어의 데비안 패키저도 신경 쓰지 않을 것입니다.
마지막으로 다음과 같이 작성합니다.
하지만 새 릴리스에서 버그가 지속되더라도 개발자는 실제로 안정 릴리스에 대해 보고된 버그에 주의를 기울일까요?
이것이 무엇을 의미하는지 이해하지 못합니다. 최신 버전에 버그가 있는 경우 최신 버전에 대해 버그를 보고해 주세요. 안정적인 릴리스에 대해 보고되는 이유는 무엇입니까?