From 886ae437fee6a674f7b2757062f1b8a91275457a Mon Sep 17 00:00:00 2001 From: Sacha Chua Date: Fri, 8 Oct 2021 01:58:03 -0400 Subject: Add talk pages for 2021 --- 2021/talks/devel.md | 88 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 88 insertions(+) create mode 100644 2021/talks/devel.md (limited to '2021/talks/devel.md') diff --git a/2021/talks/devel.md b/2021/talks/devel.md new file mode 100644 index 00000000..b3c197f4 --- /dev/null +++ b/2021/talks/devel.md @@ -0,0 +1,88 @@ +[[!meta title="Don't write that package! or: How I learned to stop worrying and love emacs-devel"]] +[[!meta copyright="Copyright © 2021 Stefan Kangas"]] +[[!inline pages="internal(2021/info/devel-nav)" raw="yes"]] + + + + +# 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. + + + + +[[!inline pages="internal(2021/info/devel-schedule)" raw="yes"]] + +[[!inline pages="internal(2021/info/devel-nav)" raw="yes"]] -- cgit v1.2.3