[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PL support

From: Richard Stallman
Subject: Re: PL support
Date: Thu, 14 May 2020 01:03:43 -0400

[[[ 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. ]]]

  > I could agree to that, but I wouldn't agree to drop all of the
  > requirements.  And even if we loosen some of them, it's already
  > problematic: the contributors of code for the core, which are
  > generally required to adhere to all of the requirements, could
  > rightfully feel they are treated unfairly, even though developing the
  > core benefits Emacs more than an unbundled package.

That is an important point.  Relaxing any standard for part of the
spectrum tends to lead to pressure to relax it elsewhere too.
But there may be ways we can reduce that pressure.

One idea is to make a clearer distinction between packages.
For instance, we could divide GNU ELPA packages into two repos, or two
classes of inclusion, with different standards.  There are various
ways to work out the details.

Another idea is to recruit someone to promise to clean the package up,
before installing it.  Then we would install the package tentatively.
If the person who promised does not do the work, we could say, "We
tentatively added XYZ to GNU ELPA after someone promised to clean it
up, but perse didn't do the work.  We can keep it tentatively in GNU
ELPA if someone else commits to do that work."

For cleanups that are purely technical, this could be effective to get
them done.

It would be useful to record, with each tentative package, a target date
for the work, and a deadline further away, at which point we would recruit
someone else or delete it.

Vital for either of these ideas to be effective is to _show_ users
these facts reasonably often if they use GNU ELPA.  Information in a
page they can look at if they are curious will not do the job.

One idea is to make package.el show the information to anyone who
installs the package.  Also, it could ask for confirmation on
installing a tentative package.  Is there a way to ask for confirmation
more often than that, but not too often?


Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]