¿Me estoy perdiendo algún lugar, donde ocurre la coordinación / desarrollo de nuevas versiones de Emacs?

Últimamente me impresionaron las cosas nuevas / mejoradas que se incluyen con Emacs 25. Luego comencé a pensar en todo el proceso detrás de él. Me gustaría compartir mis pensamientos contigo.

Mantenerse al día con las últimas solicitudes, muchas correcciones de errores, mantener, extender el núcleo / desarrollador de Emacs y lo que sea, debe ser un gran trabajo, de eso no hay duda.

Cuando verifico cuántos cambios y mejoras se implementan en Emacs 25, se deben dedicar muchas horas de desarrollo.

Requiere una coordinación bastante grande. Es como si debe haber una gran empresa detrás de todos estos cambios para impulsar aún más a Emacs. Pero no es algo rentable, es todo software libre y licencia GPL.

Entonces es de los voluntarios que están dispuestos a pasar su tiempo para impulsar a Emacs más allá, al lado de su trabajo habitual. Eso requiere algún tipo de coordinación.

Cuando revisé las listas de correo de Emacs-dev, parece que no hay mucha coordinación, no hay mucha gente participando.

Y perdóname, personalmente considero que las listas de correo son una cosa de los años 90. Hoy en día tienes alternativas más bonitas, como el rastreador de problemas de GitHub y las comunidades regulares.

Cuando miro alrededor en la web, tienes los blogs habituales (Endless Parentheses, Sacha Chua, Redux, OrEmacs, etc.) y las comunidades de Emacs (como este Emacs Exchange y, presumiblemente la comunidad más grande) reddit.com/r/emacs ) y colecciones como emacs.zeef.com y wikiemacs.

Pero no es un lugar para el desarrollo de nuevas versiones de Emacs, que requiere mucha gente y coordinación.

En algún lugar tuve la sensación de que todo esto está bajo tierra, donde se están desarrollando secretamente nuevas versiones de Emacs ... pensamiento curioso.

Todo esto me hace preguntarme si me falta algún tipo de gran punto de acceso en la web, ¿dónde sucede toda la magia?

Si bien secundo los comentarios de otros aquí sobre los lugares a donde ir para la interacción y la coordinación, hay otro aspecto único en el desarrollo de Emacs. Por su tamaño, innovación y coordinación, es un esfuerzo relativamente silencioso. No hay mucho ruido sobre sí mismo. Los lanzamientos importantes provocan unas docenas de correos electrónicos adicionales. Incluso para hilos largos, las réplicas son concisas.

Compare eso con proyectos comparables que parecen generar tanto ruido que rutinariamente me doy de baja en las listas de eventos importantes.

Esta economía de la comunicación se refleja en la madurez de las ideas y la libertad de desarrollar cualquier idea que valga la pena implementar. Las características no deseadas desaparecen en silencio mientras que las nuevas ideas (incluso si lo llamas modo malvado) obtienen una entrada en el registro de cambios.

En cuanto a los blogs que menciona, cumplen un papel importante no solo en la educación sino también en el desarrollo de ideas competitivas e ideas de apoyo. Por ejemplo, ace-jump revivió muchas ideas de saltar a otras partes del búfer, otros búferes, otros archivos, búsqueda remota, etc. Por ejemplo, ack, avy, hiedra, anzu, abogado, swiper, swoop, etc., se están refinando en este momento y son temas frecuentes de discusión en google + meet.

La suscripción al feed de Planet emacs rss probablemente cubrirá la mayoría de los blogs activos. El rss es relativamente breve excepto por una repetición ocasional de la misma noticia por parte de otra persona.

No encontrará correos electrónicos de desarrolladores sobre subfunciones en la lista de desarrolladores de Emacs, pero quizás en su propia lista de correo específica del proyecto. La mayor de estas listas de proyectos específicos es, por supuesto, el modo org. Lo que pudo haber sido cientos en esa lista probablemente se reduzca a un solo anuncio en el registro de cambios de emacs.

En lugar de una lista completa de correo electrónico para desarrolladores, un grupo usenet, un canal irc, un sitio web, una ubicación de git hub, una ubicación de blog o una página de redes sociales, tenemos una interacción verdaderamente distribuida y diversa donde ninguna plataforma única se hace cargo. Puede deberse en parte al hecho de que el desarrollo de emacs lleva mucho más tiempo que cualquiera de estas plataformas de comunicación, pero también se debe en parte a una elección deliberada de no restringir a un solo modo de comunicación.

En general, no es el caso que no haya suficiente coordinación. Como desarrollador, toma la menor cantidad de información que desea. El modelo de desarrollo de Emacs se presta a una colaboración relativamente libre de ruido (y sin fricción). Creo que eso es bueno. Espero que ustedes también.

No, no le falta nada, excepto la lista de correo de errores de Emacs: bug-gnu-emacs@gnu.org(que usa debbugs.gnu.org).

Y hay un repositorio git para el código fuente de Emacs, que es lo que se usa.

La discusión está en marcha emacs-devel@gnu.orgy bug-gnu-emacs@gnu.org. Algún código está expuesto y discutido allí.

Pero el desarrollo del código lo realizan individuos (usted, por ejemplo). Una persona puede realizar cambios en el repositorio, si tiene los privilegios / acceso necesarios, o puede enviar un parche a una de las listas de correo y pedirle a otra persona que lo aplique.

Cuando lo use M-x report-emacs-bug, puede adjuntar un parche a su informe de errores, si tiene una solución que le gustaría proponer.

La "magia" ocurre a través del desarrollo individual y comentarios / discusión.

FWIW: Common Lisp, que es un lenguaje enorme y bastante complejo, fue completamente definido (y prototipo) usando el correo electrónico, a fines de los años setenta y principios de los ochenta. Eso fue antes de la World Wide Web, cuando Internet era un niño. Los que definieron el idioma se ubicaron en varios lugares del mundo, principalmente en laboratorios de investigación. Magia, de hecho.