Czy brakuje mi jakiegoś miejsca, w którym odbywa się koordynacja / rozwój nowych wersji Emacsa?

Ostatnio byłem pod wrażeniem nowych / ulepszonych elementów, które są zawarte w Emacsie 25. Potem zacząłem myśleć o całym tym procesie. Chciałbym podzielić się z tobą moimi przemyśleniami.

Nadążanie za najnowszymi żądaniami, wiele poprawek błędów, utrzymywanie, rozszerzanie jądra / dev Emacsa i cokolwiek innego, to musi być cholernie ciężka praca, co do tego nie ma wątpliwości.

Kiedy sprawdzę, ile zmian i ulepszeń wprowadzono w Emacsie 25, trzeba poświęcić na to wiele godzin programowania.

Wymaga to dość dużej koordynacji. To tak, jakby za tymi wszystkimi zmianami musiała kryć się duża firma, aby pchnąć Emacsa dalej. Ale to nie jest opłacalne, to wszystko wolne oprogramowanie i licencja GPL.

Tak więc pochodzą od wolontariuszy, którzy są gotowi poświęcić swój czas na popychanie Emacsa dalej, obok swojej regularnej pracy. Wymaga to pewnej koordynacji.

Kiedy sprawdziłem listy mailingowe Emacs-dev, wydaje się, że koordynacja jest niewielka, niewiele osób bierze udział.

I wybaczcie, osobiście uważam, że listy mailingowe to coś z lat 90. Obecnie masz więcej ładnych alternatyw, takich jak narzędzie do śledzenia problemów GitHub i zwykłe społeczności.

Kiedy rozglądam się po Internecie, masz regularne blogi (Endless Nawiasy, Sacha Chua, Redux, OrEmacs itp.) Oraz społeczności Emacs (jak ta Emacs Exchange i - prawdopodobnie największa społeczność - reddit.com/r/emacs ) i kolekcje takie jak emacs.zeef.com i wikiemacs.

Ale nie jest to miejsce na rozwój nowych wydań Emacsa, który wymaga wielu ludzi i koordynacji.

Gdzieś mam wrażenie, że to wszystko jest pod ziemią, gdzie potajemnie rozwijane są nowe wersje Emacsa ... zabawna myśl.

To wszystko sprawia, że ​​zastanawiam się, czy brakuje mi jakiegoś dużego punktu dostępowego w Internecie, gdzie dzieje się cała magia?

Podczas gdy ja drugi komentarz tutaj na temat miejsc do interakcji i koordynacji, istnieje inny unikalny aspekt rozwoju Emacsa. Ze względu na swój rozmiar, innowację i koordynację jest to stosunkowo cicha praca. Niewiele hałasu o sobie. Główne wydania uruchamiają kilkadziesiąt dodatkowych e-maili. Nawet w przypadku długich nici retorty są zwięzłe.

Porównaj to z porównywalnymi projektami, które wydają się generować tak dużo hałasu, że rutynowo rezygnuję z subskrypcji list dotyczących ważnych wydarzeń.

Ta ekonomia komunikacji odzwierciedla dojrzałość pomysłów i swobodę rozwijania wszelkich pomysłów godnych wdrożenia. Niepożądane funkcje cichną, a nowe pomysły (nawet jeśli nazywacie je złym trybem) zostają wpisane do dziennika zmian.

Jeśli chodzi o blogi, o których wspominasz, odgrywają one ważną rolę nie tylko w edukacji, ale także w pracy nad konkurującymi pomysłami i pomysłami typu piggy backing. Na przykład ace-jump wskrzesił wiele pomysłów na przeskakiwanie do innych części bufora, innych buforów, innych plików, zdalnego wyszukiwania i tak dalej. Na przykład, ack, avy, ivy, anzu, counsel, swiper, swoop itp. Są teraz dopracowywane i są częstymi tematami dyskusji w Google + spotkania.

Subskrybowanie kanału rss planety emacs prawdopodobnie obejmie większość aktywnych blogów. Rss jest względnie zwięzły, z wyjątkiem sporadycznych powtórzeń tego samego newsa przez kogoś innego.

Nie znajdziesz e-maili programistów o podfunkcjach na liście programistów Emacsa, ale być może na ich własnej liście mailingowej dotyczącej konkretnego projektu. Największa z tych list specyficznych dla projektu to oczywiście tryb organizacji. To, co mogło być setkami na tej liście, jest prawdopodobnie sprowadzone do pojedynczego ogłoszenia w dzienniku zmian emacsa.

Zamiast wszechstronnej listy e-mail deweloperów, grupy usenet, kanału irc, witryny, lokalizacji git hub, lokalizacji na blogu lub strony w mediach społecznościowych, mamy naprawdę rozproszoną i różnorodną interakcję, w której żadna platforma nie przejmuje. Może to częściowo wynikać z faktu, że rozwój emacsa trwa znacznie dłużej niż którakolwiek z tych platform komunikacyjnych, ale częściowo wynika to również z celowego wyboru, aby nie ograniczać się do jednego rodzaju komunikacji.

Ogólnie rzecz biorąc, nie jest tak, że koordynacja jest niewystarczająca. Jako programista bierzesz tak mało lub tyle, ile chcesz. Model rozwojowy Emacsa nadaje się do stosunkowo pozbawionej hałasu (i bez tarcia) współpracy. Myślę, że to dobra rzecz. Mam nadzieję, że ty też.

Nie, niczego ci nie brakuje, z wyjątkiem listy mailingowej błędów Emacsa: [email protected](która używa debbugs.gnu.org).

I istnieje repozytorium git dla kodu źródłowego Emacsa - to jest używane.

Dyskusja trwa [email protected]i [email protected]. Niektóre kody są tam ujawnione i omówione.

Ale tworzenie kodu odbywa się przez osoby fizyczne (na przykład ty). Osoba może zatwierdzić zmiany w repozytorium, jeśli ma niezbędne uprawnienia dostępu lub uprawnienia, może przesłać łatkę na jedną z list mailingowych i poprosić kogoś innego o jej zastosowanie.

Podczas używania M-x report-emacs-bugmożesz dołączyć łatkę do swojego raportu o błędzie, jeśli masz poprawkę, którą chciałbyś zaproponować.

„Magia” odbywa się poprzez indywidualny rozwój oraz komentarze / dyskusje.

FWIW: Common Lisp, który jest obszernym językiem i dość złożonym, został całkowicie zdefiniowany (i prototypowany) za pomocą poczty elektronicznej na przełomie lat 70. i 80. To było przed World Wide Web, kiedy Internet był niemowlęciem. Osoby definiujące język znajdowały się w różnych miejscach na całym świecie, głównie w laboratoriach badawczych. Rzeczywiście magia.