From 6814670e802f646762456adcee05f4962b922e0b Mon Sep 17 00:00:00 2001 From: Stefan Kangas Date: Fri, 29 Oct 2021 02:53:34 +0200 Subject: Update my talk description in 2021/talks/devel.md --- 2021/talks/devel.md | 98 +++++++++++++---------------------------------------- 1 file changed, 24 insertions(+), 74 deletions(-) (limited to '2021/talks/devel.md') 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. - - - +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"]] -- cgit v1.2.3 From cb0a6c8f824c414af8f7bc95e70fdd4e5f71d436 Mon Sep 17 00:00:00 2001 From: Stefan Kangas Date: Fri, 29 Oct 2021 02:55:03 +0200 Subject: Fix formatting in my talk description --- 2021/talks/devel.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to '2021/talks/devel.md') diff --git a/2021/talks/devel.md b/2021/talks/devel.md index 015e8118..461f64f3 100644 --- a/2021/talks/devel.md +++ b/2021/talks/devel.md @@ -15,12 +15,12 @@ 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. +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 +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 -- cgit v1.2.3