Mnie odrzuca głównie licencja i wpis, że można pisać testy w rspecu lub test/unit. Rozumiem, że autorzy chcą zrobić dobrze zwolennikom obu frameworków, ale nawet jakbym miał jakieś preferencje w tym temacie, to bardziej wolałbym, żeby to nawet był ten mniej lubiany przeze mnie framework niż testy rozbite na pół.
Wiesz, sam bym to poprawił zamiast pisać notkę na blogu. Ale potem przeczytałem AGPL oraz o kontrakcie (!) jaki musisz podpisać zanim jakiegokolwiek Twojego patcha wciągną do upstream.
Ten kontrakt to jest żenada.
Takie umowy to standard wśród firm, które wypuszczają oprogramowanie na GPLu ale chcą zachować sobie możliwość wypuszczenia wersji komercyjnych. Tak samo jest z Mongodb, Eclipse czy Netbeams. AGPL zmusza do udostępnienia kodu wszystkim osobom korzystającym z aplikacji przez sieć, tym się różni od GPL. Ogólnie nie mam nic przeciwko, to może działać w przypadku pewnych typów aplikacji. Diaspora moim zdaniem do nich nie należy.
Radarkowi pewnie trochę głupio robić self-linka, więc ja tutaj wrzucę: artykuł oraz pod spodem gorąca dyskusja a’propos “cieni i blasków” 
jednoklikowego forkowania na Githubie:
http://radarek.jogger.pl/2010/04/19/forkuj-z-glowa/
Ja się z Radarkiem (oczywiście 
) nie zgadzam jeśli chodzi o konkluzję, ale bardzo fajny głos w dyskusji, zwłaszcza że nie mogę się nie zgodzić z poczynionymi obserwacjami (pewien chaos w forkach)
Ja tylko chciałbym dodać, że z tego co widzę, to w przypadku railsów nowe pull requesty są z reguły dużo szybciej załatwiane niż tickety na lighthouse - bez łatwych forków raczej ciężkie do uzyskania. Zresztą wystarczy zobaczyć co się dzieje na dashboardzie - jeżeli obserwujecie kilka w miarę popularnych projektów, to na pewno widzicie co jakiś czas pull requesty.
Jeżeli chaos w forkach jest jest ceną za tego typu ułatwienia, to ja jestem gotów ponieść taki wydatek.
Yehuda ostatnio pisał na Rails core, że dzięki nowemu sposobowi prezentacji pull requestów na githubie dużo łatwiej jest mu coś wrzucić w ten sposób niż poprzez patche na ligthhouse. Byłe na grupie na ten temat drobna dyskusja czy aby nie zmienić standardów.
Wydaje mi się, że cały problem by załatwił widok forków, który by pokazywał tylko to co zostało domergowane z powrotem. Można też stworzyć sobie forka ale pushować do innego brancha swojego wtedy też każdy wie o co chodzi 
Z drugiej strony czasem trudno powiedzieć, który fork jest oficjalny.
http://github.com/timcharper/calendar_date_select/ niby jest oficjalny ale nikomu się tam nie chce nic zrobić by było ok w Railsach3. Ja zrobiłem clone i poprawki ale jakoś nie widać by się nimi ktoś interesował. A jak ktoś zainteresowany to sobie znajdzie moją wersję.
Tylko pytanie czy będziesz rozwijać ten plugin? Zapewne nie. Gdybym zdecydował się na jego użycie, a potem okazało się, że nie działa z wersją 3.1 to będę musiał szukać kolejnego forka. Może się okazać iż znaleziony fork nie jest kompatybilny z Twoim i znów czekają mnie poprawki. I tak w kółko…
Problem jest moim zdaniem jeden: zbyt łatwe forkowanie połączone ze zbyt łatwym wystawianiem forka jako osobnego repo sprawia, że ludzie nie naciskają na autora głównego forka by wcielił ich zmiany przez co tworzą się niepotrzebne klony.
Będę go rozwijać tak długo i w takim stopniu w jakim mi to potrzebne podobnie jak autor oryginalnego. Jemu się przestało chcieć na wersji 2 railsów, mi się może przestać chcieć na wersji 3. Bo ja wiem czy ludzie nie naciskają… Jest ticket na oryginalnym z prośbą o support to railsów 3. Ma najwięcej punktów ze wszystkich ticketów. Wisi już dłuższy czas i autor nic z tym nie robi. No to przynajmniej niech sobie ludzie użyją mojego forka no nie ? A jeśli Ciebie czekają poprawki bo mój fork może nie działać w 3.1… No cóż takie jest życie. Give back to open source
Swoją drogą ja często oglądam diagram połączonych repozytorów żeby sprawdzić czy główny fork dba o jakość i wciela poprawki z innych repozytoriów czy raczej jest to zaniedbane. Duża liczba strzałek od głównego repo nie jest zła pod warunkiem, że sporo jest strzałek z powrotem. Wtedy widać, że ktoś aktywnie utrzymuje repozytorium. Jak widzę 15 osób, które poprawiły bugi różne i nic nie wcielone z powrotem to jest to przykre i wiem, czego się spodziewać. Że autor pewnie moich poprawek nie weźmie jak coś znajdę.
Nie wszyscy niestety mają czas i chęci by wspierać tak długo i dobrze soft jak np ludzie od capybar’y czy formtastica.
Nie do końca wiem na co narzekasz Że ludziom się nie chce dbać o wypuszczony soft open source i przez to tworzą się forki i można się pogubić ?
Tak może się stać z każdym pluginem/gemem. Niezależnie od tego czy to jest fork czy nie.
Dobrą taktyką jest instalowanie tylko gemów, które:
a) mają już duże community i widać, że się cały czas rozwijają
b) są łatwe do poprawienia w razie gdyby autor się rozmyślił z supportem
http://pivotallabs.com/users/mbarinek/blog/articles/1391-dependency-musings - tutaj jest fajny głos w dyskusji.
Na koniec chciałbym tylko dodać, że niestety coś za coś, nigdy nie można mieć wszystkiego. Szybko rozwijające się community i biblioteki nie mogą moim zdaniem istnieć razem ze stabilnością Zobaczcie na przykład na railsy. Wszyscy narzekają, że z wersji na wersję dużo rzeczy jest zmienianych i biednym programistom się aplikacje wywalają. To jest jedna strona medalu i prawda jest taka, że bez takiego podejścia railsy rozwijałyby się wolniej.
Railsy są świetnym przykładem. Zmieniają się core developerzy, istnieje masa forków, ale i tak wszyscy wiedzą, że instalujemy przez: gem install rails i mamy tę “właściwą” wersję. Ktoś z was korzystał z forka? Nie wydaje mi się. Nie jeden raz były kontrowersje, że coś w railsach brakuje, albo są zbędne rzeczy (Array#{first,second,third…} ;)), ale jak widać niepotrzebny był inny fork.
Bo railsy są za duże i zbyt popularne, żeby ktoś je forkował i utrzymywał swoją wersję, jak ktoś ma problem to z reguły uskutecznia jakieś monkey patche. Dlatego napisałem w poprzednim poście, że gemy z dużym community są bezpiecznym wyborem. Nie chciałem tego użyć jako przykładu projektu, który ma wiele używanych forków
Chodziło mi bardziej o to, że lepiej jest pracować w szybko rozwijającym się środowisku, nawet kosztem przejściowych problemów, niż w całkowicie stabilnym i kompatybilnym wstecz, które bardzo wolno się rozwija. Jakby każdy się zastanawiał czy będzie miał czas na supportowanie wypuszczonego gema, to pewnie dużo mniej by ich wychodziło. Tak samo z forkami, wolę żeby było kilka różnych forków i żebym czasami musiał wybrać któryś z nich, niż żeby projekt po prostu umarł.
Ja całkiem niedawno instalowałem (dużo powiedziane – wpisałem do Gemfile) drogomirowy fork railsów
Oraz: Radarek, atakujesz zupełnie nie ten problem.
Jasne, że istnieje problem typu “X zrobił fork dla kompatybilności z 2.1, Y wziął tego forka i dostosował do 2.2, a Z wziął i dokręcił do kompatybilności z 3.0” i nie wiadomo którą wersję wybrać oraz że każda z nich jest opuszczana (abandonware) przez forkującego po spełnieniu jego potrzeby.
ALE alternatywą wobec powyższego nie jest, jak byśmy wszyscy chcieli, “X bierze na klatę utrzymanie i rozwijanie tej biblioteki” – to są marzenia. Alternatywą wobec powyższego, przy podniesieniu trudności zrobienia forka, jest powstawanie dziesiątek wewnątrzfirmowych czy własnych wersji.
Wewnętrznych, czyli nie wypuszczanych do społeczności, która za każdym razem skazana jest na etap, na którym projekt znalazł X.
Jak ktoś nie wierzy, niech przypomni sobie czasy kiedy w środowisku królowało Subversion.
Otóż z dwojga złego ja już wolę chaos, ale ze znajdowalnymi i używalnymi forkami, niż konieczność powielania czyjejś pracy – tylko dlatego, że bariera umieszczenia forka okazała się wyższa.
Oraz, mając takie forki, istnieje bardzo realna i rzeczywista szansa, że oryginalny autor bądź jeden z forkujących weźmie na poważnie kwestię dalszego utrzymania i rozwijania projektu, tym samym kończąc chaos
PS. Możemy wydzielić dyskusję nad postem Radarka do osobnego tematu?
Tomash: Wyraziłeś w trzecim paragie swojej wiadomości dokładnie to czego nie umiałem wypowiedzieć i próbowałem nieudolnie ubrać w słowa . Myślę, że możemy wydzielić dyskuje.
Słowniczek Ruby - Polski - wynik namiętnego obcowania z książką “Metaprogramming Ruby”. W jednym miejscu po Polsku zebrane nietrywialne pojęcia z naszego ulubionego języka. Z góry dzięki za komentarze, uzupełnienia i propozycje kolejnych haseł!
Na swoim blogu opisuję rozwiązanie problemu UJS w Rails 3 w oparciu o jQuery. Opisuję tylko jedną rzecz - jak zrobić, żeby zachować semantykę klucza update w link_to_remote. Co prawda jest już wiele postów na temat UJS w Rails 3, ale nigdzie indziej nie jest napisane jak ładnie rozwiązać ten problem (nawet Ryan nie ma w tym miejscu zbyt dobrego pomysłu) - tzn. tak żeby nie musieć dla każdej akcji dodawać jednolinijkowego pliku action.js.erb. Dodam tylko, że post jest po angielsku, ale tekstu jest na tyle mało, że nawet osoba z kiepską znajomością tego języka sobie poradzi.
To jest fantastyczne rozwiązanie. Nie rozumiem, dlaczego nie ma tego w oficjalnym adapterze.
Uzupełniłem o współpracę z form_for:
jQuery(function($) {
$("a[data-update], form[data-update]").live("ajax:success", function(data,status,xhr) {
$("#"+$(this).attr("data-update")).html(status);
});
});
[quote=qertoip]jQuery(function($) {
$("a[data-update], form[data-update]").live("ajax:success", function(data,status,xhr) {
$("#"+$(this).attr("data-update")).html(status);
});
});
[/quote]
Powinno być:
jQuery(function($) {
$("a[data-update], form[data-update]").live("ajax:success", function(event, data,status,xhr) {
$("#"+$(this).attr("data-update")).html(data);
});
});
Oczywiście, dzięki.