[[!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"]]