Niedawno natknąłem się na dość irytujący (potwierdzony) błąd w pakiecie oprogramowania typu open source, który zintegrowałem z moją aplikacją. Według publicznego narzędzia do śledzenia problemów ten błąd został rozwiązany w najnowszej wersji oprogramowania.
Czasami POTRZEBUJESZ tej poprawki błędu, aby uniknąć kosztownego refaktoryzacji określonego modułu, jednak ze względów technicznych i / lub politycznych nie będzie można zaktualizować do najnowszej wersji.
Po sprawdzeniu dokonanych zmian kodu poprawka wydaje się na tyle prosta, że wydaje mi się, że realną opcją byłoby załatanie kodu i ponowne skompilowanie mojej zatwierdzonej wersji oprogramowania, jednak przeciwnicy chcą argumentować, że prawie zawsze jest to zły pomysł ponieważ jest to ryzykowne i wprowadza kłopotliwą złożoność.
W ich oczach, ponieważ ta zmiana kodu została wykonana przez nas wyłącznie na nasz użytek, musi ona być częścią naszej bazy kodu, co oznacza, że zamiast wprowadzać oprogramowanie open source jako zależność od strony trzeciej, musimy wprowadzić go jako nowy projekt i włączyć jego automatyczna kompilacja w naszym procesie kompilacji.
Dla mnie myślę, że to źle, ponieważ ściągnęlibyśmy ich kod z repozytorium kontroli źródła do naszego, a my tracimy historię za wszelkimi zmianami kodu, które nastąpiły wcześniej. Wydaje się też, że jest to coś zbyt skomplikowanego, aby wprowadzić tak małą zmianę kodu.
Czy zrobienie powyższego w tym przypadku byłoby złym pomysłem? Jeśli tak, to jaka jest idealna sytuacja, gdy trzeba zmienić open source, ale tylko dla własnej korzyści w domu?
źródło
Odpowiedzi:
Jeśli nie możesz użyć późniejszej wersji, w której nie występuje napotkany problem, jedynymi dostępnymi opcjami są albo
Byłem na twojej pozycji, opcja 2 (tworzenie niestandardowego widelca) jest często najłatwiejszym dostępnym rozwiązaniem. Takie jest życie, gdy mamy do czynienia z bibliotekami open source, zwłaszcza tymi, które ewoluują szybko i mają zły nawyk, aby zerwać wsteczną kompatybilność między wydaniami (co z mojego doświadczenia jest najczęstszym powodem, aby robić takie rzeczy).
Przez więcej niż kilka bibliotek OSS doprowadziło mnie to i zespoły, do których byłem częścią, aby zlecać owijanie dookoła każdego z nich i uzyskiwanie dostępu do funkcjonalności bibliotek stron trzecich wyłącznie przez te owijarki. W ten sposób, jeśli będziemy musieli zastąpić bibliotekę innej firmy wersją tak odmienną, że zepsuje nasz kod, zmiany będą przynajmniej w dużej mierze ograniczone do tego opakowania. Nie jest to najładniejsze (dodaje kod, może zwiększyć złożoność i wydajność kosztową), ale czasami jest to jedyny sposób na zachowanie rozsądku.
źródło
To, co masz zamiar zrobić, to zły pomysł w bardziej powszechnym przypadku, gdy łączysz oprogramowanie innych firm i zamierzasz śledzić ich wydania . Zwykle ludzie to robią, ponieważ chcą funkcji w komponencie innej firmy, której opiekunowie nie są skłonni wdrożyć lub wdrożyć w sposób, w jaki potrzebujesz.
Jednak wyraźnie powiedziałeś, że nie zaktualizujesz pakietu. To sprawia, że skutecznie jesteś opiekunem komponentu innej firmy. Dlatego to, czy łatanie jest dobrym pomysłem, czy nie, zależy tylko od tego, czy dobrze rozumiesz ten kod, aby mieć pewność co do pożądanego efektu. Testy integracyjne powinny wystarczyć do sprawdzenia, czy faktycznie robi to, co zakładasz. Dlatego, jak mówisz o sytuacji, wydaje mi się, że twoi recenzenci się mylą.
źródło
Naprawdę nie ma w tym nic złego, o ile wszyscy znoszą koszty, korzyści i ryzyko.
Kiedy masz pracę do wykonania, idealna (posiadanie biblioteki innej firmy, która jest dokładnie tym, czego chcesz) jest wrogiem wystarczająco dobrym (samodzielne załatanie jej), a czasami musisz robić takie rzeczy. Zrealizowałem wiele projektów, w których kupiliśmy licencje źródłowe dla bibliotek komercyjnych, abyśmy mogli rozwiązać problemy, zanim dostanie się od dostawcy.
Jest to zły pomysł, jeśli nie masz narzędzi do poradzenia sobie z sekcją kodu innego użytkownika, identyfikowaniem problemu i pisaniem poprawki. Dotyczy to zarówno kodu wewnętrznego, jak i strony trzeciej; jedyną różnicą jest to, czy został wyrzucony nad kabinę lub ścianę budynku, zanim wylądował na twoich kolanach.
Jeśli twoi przeciwnicy są po prostu szczotkowanie pomysł na bok bez obciążania kosztami nie robi tę poprawkę, nie robią ich pracy domowej. Jeśli masz dużo kodu wewnętrznego, na który wpływa błąd, który naprawi łatka, musisz przejść i zmienić go, aby go obejść i ponownie przetestować wszystko, aby upewnić się, że działa poprawnie. Następnie, jeśli kiedykolwiek uaktualnisz pakiet do wersji z poprawionymi błędami, być może będziesz musiał znaleźć i usunąć swoje obejścia i ponownie przetestować. Istnieje również ryzyko, że to zrobisz, na przykład pominięcie zmienionego przypadku lub niewystarczające testowanie. Osobiście, jeśli mam okazję naprawić błąd u źródła, wolałbym to zrobić tam niż gonić resztę kodu za pomocą flyswatter i mam nadzieję, że dostanę wszystko.
Jeśli robisz łatkę, łatka jest częścią twojego kodu, co oznacza, że musisz włączyć ją do swojego procesu. Nie różni się to niczym od dodania do systemu czegoś, co stanowi 100% kodu. Traktuj dystrybucję stron trzecich jako świętą i umieść ją w module tak, jak w przypadku kodu źródłowego. Wszelkie napisane łaty są przechowywane w osobnych plikach i stosowane w ramach procesu kompilacji. W ten sposób zawsze przechodzisz od czystego źródła do łatanego źródła do zbudowanego produktu i możesz dokładnie pokazać, co się dzieje. (Niektórzy rozpakowują, łatają ręcznie, ponownie pakują i przechowują to w kontroli wersji. To źle.)
Jeśli traktujesz bibliotekę innej firmy jako zależność innej firmy, nie masz na początku tej historii i nic nie tracisz. Jeśli masz stały dostęp do repozytorium strony trzeciej, możesz skonsultować się z nim w razie potrzeby. Wersje innych firm należy traktować jak amorficzne obiekty BLOB, które niezmiennie rejestrujesz we własnym systemie. Jeśli chcesz spojrzeć na zmiany między wersją, której używasz, a późniejszymi wersjami, możesz to zrobić i, jeśli chcesz, zaproponować łatki do starej wersji, które zawierają pożądane zmiany.
Jeśli proces kompilacji jest wystarczająco zaawansowany, dodanie tego nie powinno być trudniejsze niż dodanie własnego kodu. Doprowadzenie go do punktu, w którym proces rozpakowywania / łatania / kompilacji jest zautomatyzowany, wymaga niewielkiego nakładu pracy, ale po jego zakończeniu trwa wiecznie. Może być teraz jeden błąd, ale w przyszłości może być dwadzieścia. Jeśli tak, będziesz o wiele szczęśliwszy, że położyłeś podwaliny, aby wesprzeć to wszystko teraz, ponieważ sprawi, że radzenie sobie z następnymi 19 znacznie mniej pracy.
źródło
To, co chcesz zrobić, wydaje się dość rozsądne, ale wydaje się, że istnieją powody (dźwięk?) Do sprzeciwienia się temu. Nie będę porównywał proponowanych rozwiązań, ale być może istnieje sposób, abyś mógł zjeść swoje ciasto i zjeść je:
Jeśli dany projekt open source na to pozwala, przekaż poprawkę do swojego repozytorium. To znaczy, jeśli używasz wersji 1.5.2, a bieżąca stabilna wersja to 1.6.1, dodaj łatkę do wersji 1.5.2. Jeśli zostanie przyjęty, możesz pobrać stałe źródło bezpośrednio z repozytorium (być może w wersji 1.5.3) i uszczęśliwić wszystkich.
Innymi słowy: załataj to dla wszystkich, którzy są w twojej sytuacji. Oczywiście jest to możliwe tylko wtedy, gdy projekt obsługuje (lub przynajmniej zezwala) aktualizacje wydanych wersji. Ale z pewnością jest to obecnie dość standardowa praktyka.
źródło