Jak wasz pracodawca zapatruje się na wkład w rozwój projektów open source? Powiedzmy, korzystasz z biblioteki, znajdujesz w niej błąd - nie ma problemu z wysłaniem fixa do repozytorium? #programowanie
@Ginden: zazwyczaj i tak trzeba buga poprawić, żeby coś zadziałało. A skoro trzeba poprawić i korzystamy z biblioteki open source to nie widzi nic złego we wrzuceniu fixa do ogólnego repo
Nie ma z tym problemu, ogólnie to jeśli znajdziesz błąd, który Cię blokuje, to tak czy inaczej go musisz ogarnąć, albo szukać obejścia. Według mnie lepiej to sobie ogarnąć, dodać pull requesta do projektu i cieszyć się działającą biblioteką po aktualizacjach, niż robić coś dookoła a później to jeszcze utrzymywać.
@Ginden: Praktykuję dwa rodzaje wkładów do bibliotek/frameworków, z których korzystam w pracy:
1. Rozwinięcie feature'ów istniejącego kodu (bo akurat my czegoś potrzebujemy, ale po co tylko my mamy na tym skorzystać, jak potem jeszcze ktoś inny będzie nam w razie czego fixował? ;-)) 2. Bugfixy
Za pierwszym razem spytałem o pozwolenie i wysyłam PRy. Skoro jest potrzebne, to nie ma znaczenia czy leży u nas czy w źródłowym projekcie – lepiej
znajdujesz w niej błąd - nie ma problemu z wysłaniem fixa do repozytorium?
@Ginden: Mam wrażenie, że pominąłeś jeden drobny szczegół, który jest najważniejszy w tym wszystkim.
Zdiagnozowanie błędu i czas poświęcony na jego naprawę. Znaleźć błąd to jedno, natomiast naprawić... w dodatku w obcym projekcie... u mnie nie było o tym nawet mowy. Szybciej zrobić naokoło.
Zdiagnozowanie błędu i czas poświęcony na jego naprawę
@BeSmarter: I tak to robisz. Bug wykryłeś jak jego negatywny rezultat pojawił się w Twojej aplikacji. I chcesz, żeby Twoja aplikacja banglała, więc piszesz fixa.
Jaka jest różnica między pisaniem fixa na poziomie Twojej appki (żeby ominąć problem liba) vs od razu do liba, z którego korzystasz?
Być może olejesz liba i użyjesz czegoś innego (wtedy OK, choć mógłbyś „być łaskaw” i chociaż
@MacDada: Nie wszystko jest takie oczywiste i "prawa biznesu" mają tu duże znaczenie. Jeżeli firma ściga się z konkurencją i wiesz, że konkurent używa tej samej specyficznej dla dziedziny biblioteki, to bez drgnięcia palca dałbyś im na tacy rozwiązanie buga, lub nowy ficzer, który Ciebie kosztował dużo wysiłku, a oni dostaliby go na tacy? ( ͡°͜ʖ͡°)ﾉ⌐■-■
@MacDada: Pisałem Ci 10 minut odpowiedź i skasowała mi się, bo otworzyłem przypadkowo link po prawej... a więc teraz już skracając, wyciągnę samo sedno:
Jaka jest różnica między pisaniem fixa na poziomie Twojej appki (żeby ominąć problem liba) vs od razu do liba, z którego korzystasz?
Taka, że swoją aplikację znasz i wystarczy zmienić po swojej stronie output czegoś, co nie działa, a zewnętrzna biblioteka może być potężną aplikacją, której nie
Jeżeli firma ściga się z konkurencją i wiesz, że konkurent używa tej samej specyficznej dla dziedziny biblioteki, to bez drgnięcia palca dałbyś im na tacy rozwiązanie buga, lub nowy ficzer, który Ciebie kosztował dużo wysiłku, a oni dostaliby go na tacy?
@laoong: Tak. Bo to nie jest miejsce przewagi konkurencyjnej. Ani nie ma tu miejsca na „drobne złośliwości”. I nie jest to jakiś olbrzymi koszt (w większości przypadków). Serio, myślisz, że
@MacDada: Popełniasz grzech generalizacji, gdyż cała Twoja wypowiedź może mieć zastosowanie tylko do trywialnych poprawek. Poważne zmiany (niekoniecznie pod względem objętości, ale znaczenia) np. istotnie optymalizujące codeki video lub dopisujące wsparcie dla nowych ficzerów jak najbardziej można kategoryzować jako przewagę technologiczną i Twój szef może nie pozwolić Ci publikować takich zmian i może mieć rację.
@laoong: Ale mówimy to ogólnych przypadkach – w większości przypadków właśnie fix nie jest jakimś wielkim halo. Nie mówię tu o głębszych przeróbkach czy w ogóle skupieniu się na rozwoju OSS. Więc tak, przyznaję się do generalizacji – ale wydaje mi się, że jest to jednak główny temat wątku ;)
#programowanie
1. Rozwinięcie feature'ów istniejącego kodu (bo akurat my czegoś potrzebujemy, ale po co tylko my mamy na tym skorzystać, jak potem jeszcze ktoś inny będzie nam w razie czego fixował? ;-))
2. Bugfixy
Za pierwszym razem spytałem o pozwolenie i wysyłam PRy. Skoro jest potrzebne, to nie ma znaczenia czy leży u nas czy w źródłowym projekcie – lepiej
@Ginden: Mam wrażenie, że pominąłeś jeden drobny szczegół, który jest najważniejszy w tym wszystkim.
Zdiagnozowanie błędu i czas poświęcony na jego naprawę. Znaleźć błąd to jedno, natomiast naprawić... w dodatku w obcym projekcie... u mnie nie było o tym nawet mowy. Szybciej zrobić naokoło.
@BeSmarter: I tak to robisz. Bug wykryłeś jak jego negatywny rezultat pojawił się w Twojej aplikacji. I chcesz, żeby Twoja aplikacja banglała, więc piszesz fixa.
Jaka jest różnica między pisaniem fixa na poziomie Twojej appki (żeby ominąć problem liba) vs od razu do liba, z którego korzystasz?
Być może olejesz liba i użyjesz czegoś innego (wtedy OK, choć mógłbyś „być łaskaw” i chociaż
Taka, że swoją aplikację znasz i wystarczy zmienić po swojej stronie output czegoś, co nie działa, a zewnętrzna biblioteka może być potężną aplikacją, której nie
@laoong: Tak. Bo to nie jest miejsce przewagi konkurencyjnej. Ani nie ma tu miejsca na „drobne złośliwości”. I nie jest to jakiś olbrzymi koszt (w większości przypadków). Serio, myślisz, że
@laoong: Ale mówimy to ogólnych przypadkach – w większości przypadków właśnie fix nie jest jakimś wielkim halo. Nie mówię tu o głębszych przeróbkach czy w ogóle skupieniu się na rozwoju OSS. Więc tak, przyznaję się do generalizacji – ale wydaje mi się, że jest to jednak główny temat wątku ;)