Re: On Contributing To Emacs

[Philip Kaludercic <philipk@posteo.net>]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > >From straight.el/README.md:
>
> Thanks for sending me this.
>
>     > ## Features
>
>     > * Install Emacs packages listed on [MELPA], [GNU ELPA][gnu-elpa], or
>     >   [Emacsmirror], or provide your own recipes.
>
> We do not want it to refer to MELPA or Emacsmirror.
> That would put us in the position of legitimizing nonfree packages,
> and treating that distinction as a side issue.
>
> Fixing this would not be a big change, or difficult, but that
> doesn't make it less important.

I believe straight.el (the maintainer and contributors) is part of the
MELPA-adjacent "milieu", so I don't think anyone could really make them
change their mind.

This shouldn't matter either way if the important functionality is
replicated in package.el.  I have always had the impression that the
primary author (Radon Rosborough) has a tendency for over-engineering
his packages, many of which would have been welcome additions to ELPA or
Emacs, but have since been simplified or re-implemented ("CTRLF", a
isearch-in the minibuffer has "isearch-mb", "Selectrum", a narrowing
completion framework has "Vertico", "el-patch", a system to patch)

>     > * Specify package descriptions using a powerful format based on [MELPA
>     >   recipes][melpa-recipe-format] (with a familiar but improved syntax).
>
> We would need to study the consequences of this feature, before
> deciding whether we ought to support something like this.  What sorts
> of situations do people use it for?  Why aren't packages directly usable
> in the form that they are published?

* Not all packages are immediately added to an ELPA.  It is often the
  case that a developer might develop it for a while in a Git
  repository, before submitting it somewhere.  This feature allows a
  curious user to install it, as if it were a package

* The same can happen for features, a developer might maintain on a
  separate branch.  If a user is interested in testing and giving
  feedback, they might want to use this branch before it is released.

* If for whatever reason a package maintainer falls behind, and a fork
  continues development, you could simply specify the repository of the
  fork and use that instead.

-- 
	Philip Kaludercic