Mi sto perdendo un punto in cui avviene il coordinamento / sviluppo delle nuove versioni di Emacs?

Ultimamente sono rimasto impressionato dalle cose nuove / migliorate incluse in Emacs 25. Poi ho iniziato a pensare a tutto il processo dietro di esso. Vorrei condividere i miei pensieri con te.

Tenere il passo con le ultime richieste, molte correzioni di bug, mantenere, estendere il core / dev di Emacs e quant'altro, deve essere un inferno di lavoro, non c'è dubbio.

Quando controllo quali cambiamenti e miglioramenti sono stati implementati in Emacs 25, molte ore di sviluppo devono essere dedicate a questo.

Richiede un coordinamento piuttosto grande. È come se ci fosse una grande azienda dietro tutti questi cambiamenti per spingere ulteriormente Emacs. Ma non è una cosa redditizia, è tutto software gratuito e licenza GPL.

Quindi è dai volontari che sono disposti a trascorrere il loro tempo per spingere ulteriormente Emacs, accanto al loro lavoro normale. Ciò richiede una sorta di coordinamento.

Quando ho controllato le mailing list di Emacs-dev, sembra che non ci sia molto coordinamento, non molte persone stanno partecipando.

E perdonami, personalmente considero le mailing list una cosa degli anni '90. Al giorno d'oggi hai alternative più carine, come il tracker dei problemi di GitHub e le community regolari.

Quando mi guardo intorno sul web, hai i blog regolari (Endless Parentheses, Sacha Chua, Redux, OrEmacs, ecc.) E le comunità Emacs (come questo Emacs Exchange e - presumibilmente la più grande comunità - reddit.com/r/emacs ) e collezioni come emacs.zeef.com e wikiemacs.

Ma non è un posto per lo sviluppo di nuove versioni di Emacs, che richiedono molte persone e coordinamento.

Da qualche parte ho avuto la sensazione che questo fosse tutto sottoterra, dove nuove versioni di Emacs sono state segretamente sviluppate ... pensiero divertente.

Tutto questo mi fa chiedermi se mi manca una specie di grande hotspot sul web, dove accade tutta la magia?

Mentre io secondo altri commenti qui sui luoghi in cui andare per l'interazione e il coordinamento, c'è un altro aspetto unico nello sviluppo di Emacs. Per le sue dimensioni, innovazione e coordinamento, è uno sforzo relativamente tranquillo. Non molto rumore su se stesso. Le versioni principali attivano alcune dozzine di e-mail extra. Anche per fili lunghi, le storte sono concise.

Confrontalo con progetti comparabili che sembrano generare così tanto rumore che di solito annullo l'iscrizione alle liste dei grandi eventi.

Questa economia della comunicazione riflette sulla maturità delle idee e sulla libertà di sviluppare qualsiasi idea degna di essere implementata. Funzionalità indesiderate appassiscono silenziosamente mentre nuove idee (anche se la chiami modalità malvagia) ottengono una voce nel registro delle modifiche.

Per quanto riguarda i blog che menzioni, svolgono un ruolo importante non solo nell'educazione ma anche nel lavoro attraverso idee concorrenti e idee di sostegno. Ad esempio, ace-jump ha rilanciato molte idee di saltare ad altre parti del buffer, ad altri buffer, ad altri file, alla ricerca remota e così via. Ad esempio, ack, avy, edera, anzu, counsel, swiper, swoop, ecc., Sono tutti in fase di perfezionamento in questo momento e sono frequenti argomenti di discussione su google + meet up.

Iscriversi al feed planet emacs rss probabilmente coprirà i blog più attivi. L'RSS è relativamente conciso, tranne per una ripetizione occasionale della stessa notizia da parte di qualcun altro.

Non troverai le email degli sviluppatori sulle funzioni secondarie nell'elenco degli sviluppatori di Emacs, ma forse nella loro mailing list specifica per il progetto. Il più grande di questi elenchi specifici del progetto è ovviamente la modalità org. Quelle che potrebbero essere state centinaia in quella lista sono probabilmente ridotte a un singolo annuncio nel registro delle modifiche di emacs.

Invece di una lista di e-mail per sviluppatori onnicomprensiva, un gruppo usenet, un canale irc, un sito Web, una posizione git hub, una posizione blog o una pagina di social media, abbiamo un'interazione realmente distribuita e diversificata in cui nessuna singola piattaforma prende il sopravvento. Potrebbe essere in parte dovuto al fatto che lo sviluppo di emacs è andato avanti molto più a lungo di qualsiasi di queste piattaforme di comunicazione, ma è anche in parte dovuto a una scelta deliberata di non limitarsi a una singola modalità di comunicazione.

Nel complesso, non è possibile che non vi sia sufficiente coordinamento. Come sviluppatore prendi il minimo o il massimo input che desideri. Il modello di sviluppo di Emacs si presta a una collaborazione relativamente priva di rumore (e senza attrito). Penso che sia una buona cosa. Spero lo faccia anche tu.

No, non ti manca nulla, tranne la mailing list dei bug di Emacs: bug-gnu-emacs@gnu.org(che utilizza debbugs.gnu.org).

E c'è un repository git per il codice sorgente di Emacs - questo è quello che viene usato.

La discussione è attiva emacs-devel@gnu.orge bug-gnu-emacs@gnu.org. Alcuni codici sono esposti e discussi lì.

Ma lo sviluppo del codice avviene da parte di individui (tu, per esempio). Un individuo può apportare modifiche al repository, se è in possesso degli accessi / privilegi necessari o può inviare una patch a una delle mailing list e chiedere a qualcun altro di applicarlo.

Quando lo usi M-x report-emacs-bugpuoi allegare una patch alla tua segnalazione di bug, se hai una soluzione che vorresti proporre.

La "magia" avviene attraverso lo sviluppo individuale e commenti / discussioni.

FWIW: Common Lisp, che è un linguaggio enorme e piuttosto complesso, è stato interamente definito (e prototipato) usando la posta elettronica, alla fine degli anni '70 e all'inizio degli anni '80. Ciò accadeva prima del World Wide Web, quando Internet era un bambino. Quelli che definiscono la lingua erano situati in vari punti del mondo, principalmente nei laboratori di ricerca. Magia, davvero.