summaryrefslogtreecommitdiffstats
path: root/2021/talks/devel.md
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--2021/talks/devel.md88
1 files changed, 88 insertions, 0 deletions
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"]]
+
+<!-- You can manually edit this file to update the abstract, add links, etc. --->
+
+
+# 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.
+-->
+
+
+[[!inline pages="internal(2021/info/devel-schedule)" raw="yes"]]
+
+[[!inline pages="internal(2021/info/devel-nav)" raw="yes"]]