Modyfikacja aplikacji typu open source

Jaki jest ogólny przepływ pracy, gdy chcę dodać funkcję do aplikacji typu open source, której pierwotnie nie napisałem? Jak poznać kod? Jak znaleźć miejsce, które należy zmienić lub dodać? Jak mogę dokonać zmiany, nie psując niczego innego? Jak sprawdzić, czy wszystko nadal działa?
Jakie są ogólne wytyczne dotyczące takiego projektu?

open-source

— Dani
źródło

Powinieneś również przesłać swoje zmiany do projektu, zwykle jako łatkę, aby inni mogli skorzystać.

Jest jakiś protokół, wszyscy mniej więcej z niego korzystają z czasem, ale tutaj jest rozwinięty.

Pobierasz rozproszone źródło.
Zaczynasz trochę nawigować po kodzie
- Jeśli jest to program skompilowany, nauczysz się teraz, jak go skompilować.
- Jeśli nie uda ci się go skompilować, zgłoś się do autora / listy mailingowej i zapytaj o drogę
Jeśli tak naprawdę nie rozumiesz nic na temat kodu ...
- Cóż, nie, nie pytasz ich prawie.
- Upuszczasz to, ponieważ prawdopodobnie nie jesteś na równi i nie może być żadnej rzeczywistej pomocy.
- Prześlij funkcję, jeśli autor (autorzy) zaakceptuje prośby o funkcję.
Jeszcze
- Znajdziesz miejsce, które chcesz zmienić.
- Jeśli zastanawiasz się nad drobnymi szczegółami, pytasz autora / listę mailingową i wyjaśniasz swoje zamiary.
- Przechodzisz do głównego katalogu dystrybucji (najwyższy wychodzi z rozpakowywania / rozpakowywania)
- ty diff -ur . > mypatch.path
- Wysyłasz mypatch.patchdo autora, wyjaśniając, co zrobiłeś, dlaczego to zrobiłeś i (ponieważ już tam jesteś) wyraźnie oświadczasz, że zrzekasz się praw do łatki.
jeśli autorowi nie podoba się Twój wkład
- sprawdzasz, czy istnieje sposób na wydanie modyfikacji jako wtyczki
  - w takim przypadku teraz jesteś na dobrej drodze, aby zostać zarządcą wtyczek .
- jeszcze
  - rozpalasz sytuację na swoim blogu i wypuszczasz tam łatkę, możesz ją bezpłatnie pobrać i wypróbować z wyjaśnieniem i zniewagami,
  - od czasu do czasu nawiedzasz system błędów / listę mailingową, próbując kupić wsparcie dla twojej łatki. Unikaj zbanowania.
- w żadnym z tych przypadków nie rozwidlasz kodu , ponieważ jest to bardzo męczący i mało opłacalny proces, którego nie będziesz w stanie nadążyć za czasem: spowoduje to, że użytkownicy będą smutni i zdezorientowani. Widły powinny się zdarzyć tylko wtedy , gdy duża korporacja próbuje zastraszyć swoje decyzje na OSS .
jeszcze
- otrzymujesz dalsze instrukcje od tego autora (autorów)

Z boku: istnieje ostatnia alternatywa dla diff -ur .łatki i jest to sposób github .

„Rozwidlasz” ich kod na github pod swoim imieniem
(teraz masz kopię ich kodu na swoim koncie)
połącz swojego gita z twoją osobistą kopią,
wprowadź zmiany, sprawdź je,
i powiedz głównemu autorowi (autorom), aby przejrzał twój projekt github.
Jeśli im się spodoba, zsynchronizują się .
W przeciwnym razie możesz połączyć swoje „gitfork” na swoim blogu.

— ZJR
źródło

Wszystko w porządku, dopóki nie zasugerujesz OPowi, że autorzy produktu nie przyjęli nowej poprawki funkcji, nie jest jasne, czy miało to być śmieszne czy poważne, tak czy inaczej, to BARDZO zła forma skutecznego płaczu jak małe dziecko na cały świat, ponieważ zespół produktów nie lubi / nie chce twojej nowej łaty funkcji. Oczywiście, opublikuj to, ale zawsze bądź wspaniałomyślny, jeśli nie zostanie zaakceptowany, niezależnie od tego, jak nielogiczna wydaje się decyzja. -1 - FYI, z przyjemnością cofnę mój głos, jeśli to usuniesz.

— ocodo

Aplikacja, którą chcę zmienić, przestrzega ścisłego standardu, który wraz z moimi zmianami złamie ten standard. Myślę, że nawet nie jestem w stanie poprosić o nałożenie łatki.

— Dani

@Slomojo OSS jest pełen niedojrzałych ludzi, i takie rzeczy zdarzają się przez cały czas, wszyscy powinni być przygotowani do pracy jak muł, a następnie zostać odrzuceni na podstawie, że czasami są solidni, a czasem są dyskusyjni . A przynajmniej zawsze masz szansę na to, by o tym mówić i znaleźć ludzi, którzy mogą mieć rację. Teraz rozwścieczanie się byłoby złym i bardzo dziecinnym krokiem.

— ZJR

@Dani lol, naprawdę musisz wziąć łatkę i podzielić się z nią tym sposobem. Unikaj rozwidlania, ponieważ pochłonie twoje życie, to jest jak ciągłe refaktoryzowanie bez wypłaty. ... w każdym razie sprawdź listę mailingową i system zgłaszania błędów, jeśli taki istnieje, aby sprawdzić, czy ktoś byłby zainteresowany takim rozszerzeniem, może nie jesteś sam. Aaa i najlepsze byłoby to, że mieli API do rozszerzenia lub wtyczkę, do której można wprowadzić zmiany. Jest to zawsze najlepsza opcja w takich przypadkach: utrzymanie wtyczki . ... edytuje to w.

— ZJR

jeśli istnieją zautomatyzowane przypadki testowe, uruchom je przed przesłaniem poprawki.

— oenone,

Zazwyczaj

Gdyby to był przypadkowy projekt systemu operacyjnego, najprawdopodobniej naprawiłbyś drobne błędy tu i tam.

W końcu prześlesz sporo zmian jako „łatkę”.

Zwykle dostajesz prawa do zatwierdzania, jeśli twoje rzeczy są dobre.

Mówię ogólnie i tak niejasno i niespecyficznie, jak to możliwe z powodu pytania

— MattyD
źródło