새로운 Emacs 버전의 조정 / 개발이 발생하는 부분이 누락 되었습니까?

최근에 Emacs 25에 포함 된 새로운 / 개선 된 것들에 깊은 인상을 받았습니다. 그 후의 모든 과정에 대해 생각하기 시작했습니다. 내 생각을 당신과 나누고 싶습니다.

최신 요청, 많은 버그 수정, 유지 관리, Emacs 코어 / dev 확장 및 그 밖의 무엇이든간에 그것은 의심의 여지가 없어야합니다.

Emacs 25에서 구현 된 많은 변경 사항과 개선 사항을 확인할 때 많은 개발 시간이 소요됩니다.

꽤 큰 조정이 필요합니다. Emacs를 더욱 발전시키기 위해서는 이러한 모든 변화에 큰 회사가 있어야합니다. 그러나 그것은 수익성이 없으며 모든 무료 소프트웨어이며 GPL 라이센스가 있습니다.

따라서 정규직 옆에있는 Emacs를 더욱 발전시키기 위해 기꺼이 시간을 할애하는 자원 봉사자들로부터 나왔습니다. 그것은 일종의 조정이 필요합니다.

의 메일 링리스트를 확인할 때 Emacs-dev많은 조정이 이루어지지 않은 것 같습니다.

그리고 개인적으로 메일 링리스트를 90 년대의 메일 링리스트라고 생각합니다. 요즘에는 GitHub 이슈 트래커 및 일반 커뮤니티와 같은 더 많은 대안이 있습니다.

웹을 둘러 보면 일반 블로그 (끝없는 괄호, Sacha Chua, Redux, OrEmacs 등)와 Emacs 커뮤니티 (이 Emacs Exchange 등)와 아마도 가장 큰 커뮤니티 인 reddit.com/r/emacs가 있습니다. ) 및 emacs.zeef.com 및 wikiemacs와 같은 컬렉션.

그러나 많은 사람들과 조정이 필요한 새로운 Emacs 릴리스의 개발을위한 자리는 아닙니다.

어딘가에 이런 느낌이 들었습니다. 새로운 버전의 이맥스가 비밀리에 개발되고 있습니다.

이 모든 것이 웹에서 일종의 큰 핫스팟이 없는지 궁금해합니다. 모든 마술이 일어나는 곳은 무엇입니까?

emacs-development

— 르네 프로그
소스

메일 링리스트는 거의 모든 것 같아요.

— freakhill

개인적으로, 나는 그것이 한 사람의 노력으로 잘 조정되고 큰 기능이라고 믿지 않습니다. 따라서 여기서 특별한 것은 없습니다.

— wasamasa

사람들이 메일 링리스트를 왜 싫어하는지 잘 모르겠습니다. 그들은 기술적으로 훨씬 우수한 포럼이나 페이스 북과 같습니다. 농담은 웹 기반의 것보다 뚜렷한 이점이 있습니다. 많은 클라이언트를 사용하여 전자 메일을 작성 / 읽기 / 작성 / 전송할 수 있으므로 원하는 대로 환경 을 사용자 정의 할 수 있습니다. 이것은 Emacs ( 확장 가능한 편집기) 자체 의 철학에 잘 맞습니다.

— mbork

메일 링리스트는 패치 만 보낼 수 있고 이메일 계정 이상이 필요하지 않기 때문에 훌륭 합니다. 이것은 진정으로 분산 된 워크 플로우입니다. Github (브라우저에서 무료 소프트웨어가 아닌 다른 계정으로 실행해야 함)로는이 작업을 수행 할 수 없습니다.

— rekado

답변:

상호 작용과 조정을 위해 갈 곳에 대한 다른 사람들의 의견은 두 번째이지만, Emacs 개발에는 또 다른 독특한 측면이 있습니다. 규모, 혁신 및 조정 측면에서 보면 비교적 조용한 노력입니다. 그 자체에 대해 많은 소음이 없습니다. 주요 릴리스는 수십 개의 추가 이메일을 트리거합니다. 긴 실에서도 레토르트는 간결합니다.

소음을 너무 많이 발생 시켜서 주요 행사 관련 목록을 정기적으로 탈퇴하는 비슷한 프로젝트와 비교해보십시오.

이러한 의사 소통의 경제는 아이디어의 성숙도와 구현할 가치가있는 아이디어를 개발할 수있는 자유를 반영합니다. 원하지 않는 기능은 조용히 사라지고 새로운 아이디어 (악한 모드라고하더라도)가 변경 로그에 입력됩니다.

언급 한 블로그는 교육뿐만 아니라 경쟁 아이디어와 피기 백 아이디어를 통해 작업하는 데 중요한 역할을합니다. 예를 들어, ace-jump는 버퍼의 다른 부분, 다른 버퍼, 다른 파일, 원격 검색 등으로 점프하는 많은 아이디어를 되살 렸습니다. 예를 들어, ack, avy, ivy, anzu, advisor, swiper, swoop 등은 모두 세련되고 있으며 Google+ 모임에서 자주 논의되는 주제입니다.

Planet emacs RSS 피드를 구독하면 가장 활발한 블로그를 다룰 수 있습니다. rss는 다른 사람이 동일한 뉴스 항목을 가끔 반복하는 경우를 제외하고는 비교적 간결합니다.

하위 기능에 대한 개발자 이메일은 Emacs 개발자 목록이 아니라 자체 프로젝트 별 메일 링 목록에서 찾을 수 있습니다. 이 프로젝트 별 목록 중 가장 큰 것은 물론 org-mode입니다. 이 목록에 수백 개가되었을 수도있는 것은 아마도 이맥스 변경 로그에서 한 번의 발표로 축소되었을 것입니다.

모든 것을 포괄하는 개발자 이메일 목록, 유즈넷 그룹, irc 채널, 웹 사이트, git hub 위치, 블로그 위치 또는 소셜 미디어 페이지 대신 단일 플랫폼이 차지하지 않는 진정한 분산 및 다양한 상호 작용이 있습니다. emacs 개발이 이러한 통신 플랫폼보다 훨씬 오래 진행되었다는 사실 때문일 수도 있지만 단일 통신 모드로 제한하지 않는 의도적 인 선택 때문이기도합니다.

전체적으로 조정이 충분하지 않은 경우는 아닙니다. 개발자는 원하는만큼 또는 거의 입력을받지 않습니다. Emacs의 개발 모델은 비교적 소음이없고 (마찰이없는) 협업에 적합합니다. 나는 그것이 좋은 것이라고 생각합니다. 나는 당신도 그렇게 바랍니다.

— 이맥스 사용자
소스

아니요, Emacs 버그 메일 링리스트 bug-gnu-emacs@gnu.org()를 제외하고는 아무것도 빠진 것이 없습니다 debbugs.gnu.org.

그리고 Emacs 소스 코드를위한 git 저장소가 있습니다-그것이 사용되는 것입니다.

토론이 켜져 emacs-devel@gnu.org와 bug-gnu-emacs@gnu.org. 일부 코드가 공개되어 논의되었습니다.

그러나 코드 개발은 개인에 의해 수행됩니다 (예 : 귀하). 개인이 필요한 액세스 / 권한을 가지고 있거나 메일 링리스트 중 하나에 패치를 제출하여 다른 사람에게 적용하도록 요청할 경우 저장소에 변경 사항을 적용 할 수 있습니다.

사용할 때 M-x report-emacs-bug제안한 수정 사항이있는 경우 버그 보고서에 패치를 첨부 할 수 있습니다.

"마법"은 개별 개발 및 의견 / 토론을 통해 발생합니다.

FWIW : 엄청나게 복잡한 언어 인 Common Lisp는 1970 년대 후반과 1980 년대 초에 이메일을 사용하여 완전히 정의되고 프로토 타입 화되었습니다. 인터넷이 유아였던 월드 와이드 웹 이전이었습니다. 언어를 정의하는 사람들은 전 세계 여러 곳, 주로 연구 실험실에있었습니다. 참으로 마술.

— 드류
소스