[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why are so many great packages not trying to get included in GNU Ema

From: Jean-Christophe Helary
Subject: Re: Why are so many great packages not trying to get included in GNU Emacs? WAS: Re: Making Emacs more friendly to newcomers
Date: Fri, 24 Apr 2020 11:02:57 +0900

> On Apr 24, 2020, at 9:51, chad <address@hidden> wrote:
> On Thu, Apr 23, 2020 at 4:46 PM Jean-Christophe Helary <address@hidden> wrote:
> > On Apr 24, 2020, at 2:07, Stefan Kangas <address@hidden> wrote:
> > - Misconceptions about how hard it is to work with emacs-devel.
> That's something that documentation can fix.
>  I'm not sure how. I think the widespread conception is that working with 
> emacs-devel is more difficult than working with many, many other free- and 
> open-source projects, and I think that conception is correct.

That depends on where you come from. A lot of people have not been contaminated 
by the entitlement that comes with the "I'm sending a PR, please check it in" 
generated by the Github culture. I'm not saying that PRs are bad, just that a 
lot of people think that whatever they do is OK.

Documenting means stating that Emacs is not just another "open source project 
you can contribute to in the weekends" (although that's also possible). It is 
Free Software and it is robust and it is here to last. All that comes with 
requirements and that's fair.

> Compared to "fork the project and submit a pull request" or "publish a 
> package on melpa", following emacs' patch guidelines is harder.

Please. As a totally non-developer I was able, with the guidance of a lot of 
people here, to follow the rules and get some code in the emacs core code and 
in package.el. Yes, it is harder because the requirements are different.

> Emacs requires additional paperwork.

I proposed a solution in my suggestions.

> Updating the documentation (NEWS, Changelog, the info manuals) is harder and 
> involves tools, tech, and practices that are unfamiliar to most potential 
> developers.

And if they can learn emacs-lisp enough to contribute something, they can 
certainly learn a few extra things.

> Using debbugs has improved a lot in the past few years, but is still a 
> pain-point for many. Following the emacs-devel mailing list is, let's say, 
> not a welcoming experience for everyone.

It is an *always* enriching experience.

> That doesn't even touch on the difficulties of interacting with the core.
> I think that the end result of emacs' processes is high-quality code that 
> runs on many more systems than the vast majority of software, but I don't 
> think most new developers are shying away from working on emacs because of 
> the lack or quality of the documentation.

Maybe we're not talking about the same thing ?

When I say document the process, I mean putting it in nice colors on the web 
site, so as to ease the pain for people who are used to nice colors on web 
sites but who can still go deeper and commit themselves to serious code.

Jean-Christophe Helary
http://mac4translators.blogspot.com @brandelune

reply via email to

[Prev in Thread] Current Thread [Next in Thread]