업그레이드 할 때 오픈 소스 소프트웨어를 패치하는 것은 옵션이 아닙니까?

최근에 애플리케이션에 통합 한 오픈 소스 소프트웨어 패키지에서 다소 성가신 (확인 된) 버그가 발생했습니다. 공개 이슈 트래커에 따르면이 버그는 소프트웨어의 최신 릴리스에서 해결되었습니다.

때로는 특정 모듈의 비싼 리팩터링을 피하기 위해 버그 수정이 필요하지만 기술 및 / 또는 정치적 이유로 최신 릴리스로 업그레이드 할 수 없습니다.

코드 변경 사항을 검사 할 때 수정 프로그램은 코드를 직접 패치하고 현재 승인 된 소프트웨어 버전을 다시 컴파일하는 것이 가능한 옵션이라고 생각할 정도로 간단 해 보이지만, 낙담자는 거의 항상 나쁜 생각이라고 주장하고 싶습니다. 그것은 위험하고 번잡 한 복잡성을 초래한다는 점에서.

이 코드 변경은 오직 우리의 용도로만 수행 되었기 때문에 우리의 코드 기반의 일부 여야합니다. 즉, 오픈 소스 소프트웨어를 타사의 의존성으로 도입하기보다는 새로운 프로젝트로 도입하고 통합해야합니다. 빌드 프로세스에 자동화 된 빌드.

필자는 소스 제어 저장소에서 코드를 코드로 가져갈 때 잘못된 방향으로 가고 있다고 생각합니다. 또한 작은 코드 변경이 필요하기에는 너무 복잡한 것 같습니다.

이 경우 위의 작업을 수행하는 것이 좋지 않습니까? 그렇다면 오픈 소스를 변경해야 할 때 가장 이상적인 상황은 무엇입니까?

발생한 문제가없는 최신 버전을 사용할 수없는 경우 유일한 옵션은

• 문제를 해결하고 해결 방법을 찾으십시오.
• 라이브러리를 포크하고 개인 버전으로 수정하십시오 (효과적으로 수행중인 작업입니다)
• 수건에 던져 문제를 극복 할 수 없다고 관리자에게 알리십시오.

나는 당신의 입장에 있었고 옵션 2 (맞춤식 포크 만들기)는 종종 가장 맛있는 솔루션입니다. 오픈 소스 라이브러리, 특히 빠르게 발전하고 릴리스간에 하위 호환성을 깨는 나쁜 습관이있는 라이브러리를 다루는 것은 인생입니다 (제 경험상 이와 같은 일을 해야하는 가장 일반적인 이유입니다).
몇몇 OSS 라이브러리의 경우 저와 팀을 이끌었습니다. 저는 모든 래퍼를 감싸고 래퍼를 통해 타사 라이브러리의 기능에 액세스하는 일에 참여했습니다. 이렇게하면 타사 라이브러리를 너무 다른 버전으로 바꿔야 코드가 손상 될 수 있습니다. 변경 사항은 적어도 래퍼로 제한됩니다. 가장 좋지는 않지만 (코드 추가, 복잡성 및 비용 성능 추가 가능) 때로는 정신 건강을 유지하는 유일한 방법 일 수도 있습니다.

타사 소프트웨어를 번들로 제공 하고 릴리스를 추적하려는 보다 일반적인 경우에는 나쁜 생각입니다 . 일반적으로 관리자는 유지 관리자가 구현하지 않거나 원하는 방식으로 구현하지 않는 타사 구성 요소의 기능을 원하기 때문에 그렇게합니다.

그러나 번들 코드를 업그레이드 하지 않겠다고 명시 적으로 말했습니다 . 이를 통해 타사 구성 요소를 효과적으로 유지 관리 할 수 ​​있습니다. 따라서 패치를 적용하는 것이 좋은지 아닌지 는 원하는 효과를 확신 할 수있을만큼 코드를 잘 이해 하고 있는지 여부에 달려 있습니다. 통합 테스트는 실제로 가정 한대로 수행되는지 확인하기에 충분해야합니다. 따라서 상황을 말하면 리뷰어가 틀린 것 같습니다.

모든 사람이 비용, 혜택 및 위험을 극복 할 수있는 한 실제로 그렇게하는 데 아무런 문제가 없습니다.

... 수정은 코드 자체를 패치하기에 충분히 간단 해 보입니다.

당신이해야 할 일이있을 때, 완벽한 (제대로 원하는 제 3 자 라이브러리를 갖는)은 충분히 좋은 적입니다 (직접 패치). 때로는 그런 일을해야합니다. 상용 라이브러리에 대한 소스 라이센스를 구입하여 공급 업체에 도달하기 전에 문제를 해결할 수있는 여러 프로젝트를 수행했습니다.

... 변호사들은 이것이 위험하고 귀찮은 복잡성을 초래한다는 점에서 거의 항상 나쁜 생각이라고 주장하기를 원합니다.

다른 사람의 코드를 해부하고 문제를 식별하고 수정을 작성하는 데 필요한 정보가없는 경우 나쁜 생각입니다. 코드가 사내 또는 타사인지 여부는 사실입니다. 유일한 차이점은 무릎에 떨어지기 전에 칸막이 벽이나 건물 벽에 던져 졌는지 여부입니다.

이 패치를 수행 하지 않는 데 드는 비용을 들이지 않고 비난자가 아이디어를 무시 하고 있다면 숙제를하지 않는 것입니다. 패치로 해결 될 버그의 영향을받는 많은 사내 코드가있는 경우, 문제를 해결하고 수정하여 올바르게 작동하는지 확인하기 위해 코드를 변경하고 변경해야합니다. 그런 다음 패키지를 버그 수정 버전으로 업그레이드 한 경우 해결 방법을 찾아 제거하고 다시 테스트해야 할 수도 있습니다. 변경 한 사례가 없거나 테스트가 불충분 한 경우와 같이 그렇게 할 위험도 있습니다. 개인적으로 소스에서 버그를 해결할 수있는 기회가 있다면 flyswatter로 나머지 코드를 쫓아 모든 것을 얻을 수 있기를 바랍니다.

... 코드 변경은 우리에 의해 이루어졌습니다 ... 코드 기반의 일부 여야합니다 ... 새로운 프로젝트로 소개하고 자동화 된 빌드를 빌드 프로세스에 통합해야합니다.

패치를 수행하는 경우 패치는 자체 코드의 일부이므로 프로세스의 일부로 만들어야합니다. 이것은 시스템에 100 % 코드를 추가하는 것과 다르지 않습니다. 타사 배포판을 성사로 취급하고 소스 코드처럼 모듈에 넣습니다. 작성한 모든 패치는 별도의 파일로 저장되며 빌드 프로세스의 일부로 적용됩니다. 이렇게하면 항상 깨끗한 소스에서 패치 된 소스로, 빌드 된 제품으로 가서 진행 상황을 정확하게 보여줄 수 있습니다. (일부 사람들은 버전 관리에서 압축을 풀고 핸드 패치하고 다시 포장하여 저장합니다.

... 우리는 소스 제어 저장소에서 코드를 코드로 가져오고 코드 변경의 역사를 잃어 버립니다 ...

써드 파티 라이브러리를 써드 파티 종속성으로 취급하는 경우, 해당 히스토리가 시작되지 않으며 아무것도 손실되지 않습니다. 타사의 저장소에 계속 액세스 할 수 있으면 필요한 사항을 상담 할 수 있습니다. 타사 릴리스는 변경되지 않은 자체 시스템에 체크인하는 비정질 얼룩처럼 처리해야합니다. 사용중인 릴리스와 이후 릴리스 사이의 변경 사항을 확인해야 할 경우 원하는 변경 사항이 포함 된 이전 버전에 대한 패치를 제공 할 수 있습니다.

또한 작은 코드 변경이 필요하기에는 너무 복잡한 것 같습니다.

빌드 프로세스가 충분히 정교하다면이를 추가하는 것이 자신의 코드를 추가하는 것보다 어렵지 않아야합니다. 압축 풀기 / 패치 / 빌드 프로세스가 자동으로 수행되는 시점까지는 약간의 노력이 필요하지만 일단 완료되면 영원히 끝납니다. 지금은 하나의 버그가있을 수 있지만 앞으로 20 개가있을 수 있습니다. 있다면 다음 19 개의 작업을 훨씬 덜 처리 할 수 ​​있기 때문에 지금은 모든 것을 지원할 수있는 토대를 마련한 것이 훨씬 더 행복 할 것입니다.

당신이하고 싶은 것은 충분히 합리적으로 보이지만 그것을 반대 해야하는 (사운드?) 프로세스 이유가있는 것처럼 들립니다. 제안 된 솔루션을 비교하지는 않지만 케이크를 먹고 먹을 수있는 방법이 있습니다.

해당 오픈 소스 프로젝트에서 허용하는 경우 백 포트 버그 수정을 해당 저장소에 제공하십시오. 즉, 버전 1.5.2를 사용하고 현재 안정 버전이 1.6.1이면 패치를 1.5.2에 제공하십시오. 채택되면 리포지토리에서 직접 고정 소스를 가져와 (아마도 버전 1.5.3) 모든 사람을 행복하게 할 수 있습니다.

다시 말해, 상황에있는 다른 모든 사람들을 위해 패치하십시오. 물론 이것은 프로젝트가 릴리스 된 버전에 대한 업데이트를 지원하거나 최소한 허용하는 경우에만 가능합니다. 그러나 요즘에는 확실히 표준 연습입니다.