diff options
Diffstat (limited to '2021/talks')
| -rw-r--r-- | 2021/talks/devel.md | 98 |
1 files changed, 24 insertions, 74 deletions
diff --git a/2021/talks/devel.md b/2021/talks/devel.md index b3c197f4..015e8118 100644 --- a/2021/talks/devel.md +++ b/2021/talks/devel.md @@ -8,80 +8,30 @@ # Don't write that package! or: How I learned to stop worrying and love emacs-devel Stefan Kangas -Emacs' greatest strength is also its greatest weakness: it is **too** hackable. - -We have a great community that experiment with new features that are still -lacking in Emacs core. They write up a package and develop the living daylights -out of it, until it is basically amazing. (I'm looking at you Magit.) - -There are other examples such as helpful.el - great package, but why are those -features not in core? What about projectile? And so on. - -Core demands copyright assignments (CLA). This is a fact of life. While I -mostly agree with the people saying it is not helful, they are there to protect -Emacs from copyright issues in the future. So my suggestion here is simple: -just **sign the papers**. It is just a formality, and you should only need to do -it once. - -I suggest that any ambitious feature that we **might** want to see shipped in the -default Emacs distribution should by default go to GNU ELPA. You don't need to -do this, of course, and I respect your decision, but I urge you to do it. - -GNU ELPA does not have an exceptionally high standard, but we do try to give any -new package a proper code review. - -MELPA is excellent. We love MELPA. They don't have a criterion for their -packages that is important to the FSF, which is to not recommend non-free -software. Therefore, we could not recommend it by default, and had to build -NonGNU ELPA. - -NonGNU ELPA will be used for packages that we don't have an assignment for but -would still like to distribute. It should ideally only be for old packages -where getting a CLA is impractical. - -It is sometimes perceived as hard to contribute to Emacs core. This impression -is largely wrong. If I can do it, you can too. - -We do have a problem in that our tools and methods (mailing lists, the bug -tracker) are out-dated. This is largely correct. We want to migrate to -something else, and the best candidate is probably Sourcehut. Please volunteer -to help! - -We sometimes see people adding stuff to their Init file to fix this or that -annoyance, or even bug. The more ambitious would go on to package up such fixes -in what I call "patch packages". "Hey, foo-mode doesn't have support for -'bookmark-set', let's write a package!" I am here to suggest that you submit a -patch to Emacs instead. - -Fixing an issue for one person is good, and fixing it for more people is even -better. Fixing it for everyone? Priceless. - -emacs-devel is not that scary, nor is email. We are really quite friendly and -easy going, but the communication we prefer (for reasons of efficiency - the -volume is very high) is often very brief and to the point. We are trying our -best at communicating, but sometimes fail. - -And we need more contributors. We need a successful Emacs on this planet. - -So should you really write a package, or should YOU become a core contributor? - - - -# Outline - -- I will urge people to consider contributing to Emacs instead of - writing small packages, and explain GNU ELPA, MELPA, CLA. -- I will go into greater detail about emacs-devel, how it "works" - (e.g. is Emacs conservative without reason?), how to get things - done and the necessary mindset. - -<!-- -- 40 minutes: (brief description/outline): All of the above, and I will show a - demonstration and give instructions for how to use M-x debbugs to read the bug - tracker, how to send emails, patches, and our workflows. More on what to - expect. ---> - +We need a successful Emacs on this planet. This means that we need an +excellent out-of-the-box experience -- one that just works, but that you +can still hack and customize. There is so much great experimentation +and work going on out there in the wider Emacs community, but we would +be even better off if more of that could go into Emacs itself. + +Emacs' greatest strength is unfortunately sometimes also its greatest +weakness: it is **too** hackable. + +On occasion, people out there add stuff to their Init file to fix this +or that annoyance, or even bug. The more ambitious might go on to +package up such fixes: "Hey, `foo-mode` doesn't have support for +`bookmark-set`, let's write a package!" I am here to suggest that you +should not do that. + +You should submit a patch to Emacs! Maybe more people have that same +problem or annoyance, and would benefit from your solution? + +It is sometimes perceived as hard to contribute to Emacs core. I want +to encourage more people to get involved, and show that the barrier to +entry is really not that high. If I can do it, you can do it too! + +So should you really write that package, or should you stop worrying and +learn to love emacs-devel? Listen to my talk to find out more! [[!inline pages="internal(2021/info/devel-schedule)" raw="yes"]] |