summaryrefslogtreecommitdiffstats
path: root/2021/talks
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--2021/talks/devel.md98
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"]]