Vá phần mềm nguồn mở khi nâng cấp không phải là một lựa chọn?

Gần đây tôi đã gặp phải một lỗi khá khó chịu (đã được xác nhận) trong gói phần mềm nguồn mở mà tôi đã tích hợp vào ứng dụng của mình. Theo trình theo dõi vấn đề công cộng, lỗi này đã được giải quyết trong bản phát hành phần mềm mới nhất.

Đôi khi, bạn CẦN sửa lỗi đó để tránh một bộ tái cấu trúc đắt tiền của một mô-đun cụ thể, tuy nhiên vì lý do kỹ thuật và / hoặc chính trị, bạn sẽ không thể nâng cấp lên bản phát hành mới nhất.

Khi kiểm tra các thay đổi mã được thực hiện, cách khắc phục có vẻ đơn giản đến mức tôi cảm thấy một lựa chọn khả thi sẽ là tự vá mã và biên dịch lại phiên bản phần mềm đã được phê duyệt hiện tại của tôi, tuy nhiên những người gièm pha muốn tranh luận rằng đây gần như luôn là một ý tưởng tồi trong đó là rủi ro và giới thiệu một sự phức tạp rắc rối.

Trong mắt họ vì việc thay đổi mã này chỉ do chúng tôi thực hiện để sử dụng, nó phải là một phần của cơ sở mã của chúng tôi, nghĩa là thay vì giới thiệu phần mềm nguồn mở như một sự phụ thuộc của bên thứ ba, chúng tôi phải giới thiệu nó như một dự án mới và kết hợp nó nó tự động xây dựng vào quá trình xây dựng của chúng tôi.

Đối với tôi, tôi nghĩ rằng điều này là sai lầm, vì chúng tôi sẽ kéo mã của họ từ kho lưu trữ kiểm soát nguồn của họ vào chúng tôi và chúng tôi mất lịch sử đằng sau bất kỳ thay đổi mã nào xảy ra trước đó. Ngoài ra, có vẻ như một cái gì đó quá phức tạp đối với một thay đổi mã nhỏ như vậy cần phải được thực hiện.

Nó sẽ là một ý tưởng tồi để làm ở trên trong trường hợp này? Nếu vậy, thì tình huống lý tưởng khi nguồn mở cần thay đổi là gì, nhưng chỉ vì lợi ích duy nhất của bạn trong nhà?

Nếu bạn không thể sử dụng phiên bản mới hơn mà không gặp phải sự cố bạn gặp phải, các tùy chọn duy nhất bạn có là

• sống với vấn đề và tìm cách giải quyết
• rẽ nhánh thư viện và sửa nó trong phiên bản riêng tư của bạn (đó là những gì bạn thực sự đang làm)
• ném vào khăn và nói với người quản lý của bạn rằng vấn đề là không thể vượt qua (đó sẽ là một lời nói dối, vì bạn có hai lựa chọn khác mở ra cho bạn).

Tôi đã ở vị trí của bạn, tùy chọn 2 (tạo một ngã ba tùy chỉnh) thường là giải pháp hợp lý nhất hiện có. Đó là cuộc sống khi làm việc với các thư viện nguồn mở, đặc biệt là các thư viện phát triển nhanh và có thói quen xấu phá vỡ tính tương thích ngược giữa các bản phát hành (theo kinh nghiệm của tôi là lý do phổ biến nhất để làm những việc như thế này).
Đối với nhiều thư viện OSS, tôi và các nhóm tôi đã tham gia để bắt buộc các trình bao bọc xung quanh bất kỳ và tất cả chúng và truy cập chức năng của các thư viện bên thứ 3 thông qua các trình bao bọc đó. Theo cách đó, nếu chúng ta cần thay thế thư viện của bên thứ 3 bằng một phiên bản quá khác biệt, nó sẽ phá vỡ mã của chúng tôi, những thay đổi ít nhất phần lớn bị giới hạn trong trình bao bọc đó. Nó không phải là tốt nhất (thêm mã, có thể thêm độ phức tạp và hiệu suất chi phí) nhưng đôi khi đó là cách duy nhất để giữ sự tỉnh táo của bạn.

Những gì bạn sắp làm là một ý tưởng tồi trong trường hợp phổ biến hơn khi bạn gói phần mềm của bên thứ ba và có ý định theo dõi các bản phát hành của họ . Thông thường mọi người làm điều đó bởi vì họ muốn một tính năng trong thành phần của bên thứ ba mà các nhà bảo trì không sẵn sàng thực hiện hoặc thực hiện theo cách bạn cần.

Tuy nhiên, bạn nói rõ ràng rằng bạn sẽ không nâng cấp mã được gói. Điều đó làm cho bạn có hiệu quả duy trì thành phần của bên thứ ba. Do đó, việc vá nó có phải là một ý tưởng tốt hay không chỉ phụ thuộc vào việc bạn hiểu mã đó đủ tốt để tự tin về hiệu quả mong muốn hay không. Các bài kiểm tra tích hợp của bạn phải đủ để xác minh rằng trên thực tế, đó là thực hiện những gì bạn giả định. Do đó, khi bạn nói tình hình, dường như với tôi rằng những người đánh giá của bạn đã sai.

Thực sự không có gì sai khi làm điều đó miễn là mọi người đều có thể kiểm soát được chi phí, lợi ích và rủi ro.

... cách khắc phục có vẻ đơn giản ... để tự vá mã

Khi bạn có một công việc phải làm, hoàn hảo (có thư viện của bên thứ ba chính xác là những gì bạn muốn) là kẻ thù đủ tốt (tự vá nó), và đôi khi bạn phải làm những việc như vậy. Tôi đã thực hiện một số dự án mà chúng tôi đã mua giấy phép nguồn cho các thư viện thương mại để chúng tôi có thể khắc phục sự cố trước khi nhà cung cấp nhận được.

... Những kẻ gièm pha muốn tranh luận rằng đây gần như luôn là một ý tưởng tồi trong đó là rủi ro và gây ra một sự phức tạp rắc rối.

Đó là một ý tưởng tồi nếu bạn không có các bộ xử lý để phân tích mã của người khác, xác định một vấn đề và viết một bản sửa lỗi. Điều đó đúng cho dù mã trong nhà hay bên thứ ba; sự khác biệt duy nhất là liệu nó có bị ném qua một hình khối hoặc bức tường tòa nhà trước khi nó rơi vào lòng bạn hay không.

Nếu những kẻ gièm pha của bạn chỉ đơn giản là gạt ý tưởng sang một bên mà không cân nhắc chi phí khi không thực hiện bản vá này, thì họ đã không làm bài tập về nhà. Nếu bạn có nhiều mã nội bộ bị ảnh hưởng bởi lỗi mà bản vá của bạn sẽ sửa, bạn sẽ phải trải qua và thay đổi nó để xử lý xung quanh nó và kiểm tra lại mọi thứ để chắc chắn rằng nó hoạt động chính xác. Sau đó, nếu bạn từng nâng cấp gói lên phiên bản sửa lỗi, bạn có thể phải tìm và xóa các cách khắc phục của mình và kiểm tra lại. Cũng có những rủi ro khi làm điều đó, như bỏ lỡ một trường hợp bạn đã thay đổi hoặc không đủ kiểm tra. Cá nhân, nếu tôi có cơ hội sửa một lỗi tại nguồn của nó, tôi thà làm điều đó hơn là đuổi theo phần còn lại của mã bằng một cái flyswatter và hy vọng tôi có được mọi thứ.

... thay đổi mã được thực hiện bởi chúng tôi ... nó phải là một phần của cơ sở mã của chúng tôi ... chúng tôi phải giới thiệu nó như một dự án mới và kết hợp xây dựng tự động của nó vào quá trình xây dựng của chúng tôi.

Nếu bạn đang thực hiện một bản vá, bản vá là một phần của mã của riêng bạn, điều đó có nghĩa là bạn phải biến nó thành một phần của quy trình. Điều này không khác gì việc thêm một cái gì đó 100% mã của bạn vào hệ thống của bạn. Hãy coi phân phối của bên thứ ba là bất khả xâm phạm và đưa nó vào một mô-đun giống như mã nguồn. Bất kỳ bản vá nào bạn viết đều được lưu trữ trong các tệp riêng biệt và được áp dụng như một phần của quy trình xây dựng. Bằng cách đó, bạn luôn đi từ nguồn sạch sang nguồn được vá cho sản phẩm được xây dựng và có thể hiển thị chính xác những gì đang diễn ra. (Một số người giải nén, vá tay, đóng gói lại và lưu trữ trong kiểm soát phiên bản. Điều đó thật tệ.)

... Chúng tôi sẽ kéo mã của họ từ kho lưu trữ kiểm soát nguồn của họ vào của chúng tôi và chúng tôi mất lịch sử đằng sau bất kỳ thay đổi mã nào ...

Nếu bạn coi thư viện của bên thứ ba là phụ thuộc của bên thứ ba, bạn không có lịch sử đó để bắt đầu và bạn sẽ không mất gì cả. Nếu bạn có quyền truy cập liên tục vào kho lưu trữ của bên thứ ba, bạn có thể tham khảo ý kiến ​​mà bạn cần. Các bản phát hành của bên thứ ba nên được xử lý như các đốm vô định hình mà bạn kiểm tra vào hệ thống của riêng bạn không bị thay đổi. Nếu bạn cần xem xét các thay đổi giữa bản phát hành bạn đang sử dụng và bản phát hành mới hơn, bạn có thể làm điều đó và, nếu bạn muốn, đưa ra các bản vá cho phiên bản cũ kết hợp các thay đổi bạn muốn.

Ngoài ra, có vẻ như một cái gì đó quá phức tạp đối với một thay đổi mã nhỏ như vậy cần phải được thực hiện.

Nếu quy trình xây dựng của bạn đủ tinh vi, việc thêm điều này sẽ không khó khăn hơn việc thêm mã của riêng bạn. Có một lượng lao động nhỏ để đưa nó đến điểm mà quá trình giải nén / vá / xây dựng là tự động, nhưng một khi nó được thực hiện, nó sẽ được thực hiện mãi mãi. Có thể có một lỗi bây giờ, nhưng có thể có hai mươi trong tương lai. Nếu có, bạn sẽ vui hơn nhiều khi bạn đặt nền tảng để hỗ trợ tất cả những điều đó ngay bây giờ, bởi vì nó sẽ giúp giải quyết 19 công việc tiếp theo ít hơn nhiều.

Những gì bạn muốn làm có vẻ đủ hợp lý, nhưng có vẻ như có lý do quá trình (âm thanh?) Để phản đối nó. Tôi sẽ không so sánh các giải pháp được đề xuất, nhưng có lẽ có một cách bạn có thể có bánh của bạn và cũng ăn nó:

Nếu dự án nguồn mở được đề cập cho phép, hãy đóng góp lỗi sửa lỗi cổng vào kho lưu trữ của họ. Đó là, nếu bạn đang sử dụng phiên bản 1.5.2 và phiên bản ổn định hiện tại là 1.6.1, hãy đóng góp một bản vá cho 1.5.2. Nếu nó được chấp nhận, bạn có thể tìm nạp nguồn cố định trực tiếp từ kho lưu trữ (có thể là phiên bản 1.5.3) và khiến mọi người hài lòng.

Nói cách khác: Hãy vá nó cho những người khác trong hoàn cảnh của bạn. Tất nhiên điều này chỉ có thể nếu dự án hỗ trợ (hoặc ít nhất là cho phép) cập nhật lên các phiên bản đã phát hành. Nhưng đó chắc chắn là tiêu chuẩn thực hành ngày nay.