Re: access to ELPA development packages?

[Philip Kaludercic]

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. ]]]
>
>   > I fear that promoting the devel repo might have people use it even if
>   > they don't have to, leading to the same kinds of issues that MELPA has.
>
> I don't know whether this is a valid concern, but I think the issue is
> important enough that we need to discuss whether it is a valid concern.
>
> Could you please explain the problematical usage scenario that you
> have in mind?

MELPA primarily advertises the non-stable channel, that creates a new
package version for commit in a package repository (like ELPA devel).

The problems that arise from this is that different users receive more
or less random snapshots, which is especially critical when packages
depend on one another, updating packages involves a lot more "luck" than
should be necessary. I think the argument has been insinuated in this
thread, that this makes it easier to catch bugs early, but I don't think
every user should have to deal with that (after all, any freedom,
including software freedom, should also include the freedom to say
"no"). And setting that aside, package.el doesn't provide a good basis
for development and contributing -- if you want to do more than
debugging or changing something that should be more persistent, you'll
have to clone the source manually.

Two issues specific to MELPA is that a lot of "stable" packages depend
on "unstable" packages, that might have not received a stable release,
or marked as such (MELPA requires manual tagging of releases using git
tags), so that some packages just do not release stable versions at all,
splitting the repository. The second issue is that MELPA (unstable)
generates version tags directly from the commit data, resulting in
versions like "20210721.2003". ELPA devel handles this better by
appending the date to the actual version: "0.9.13.0.20210721.211455"
(both of these version tags were taken from the company package). This
makes switching between repositories easer to handle.

For most users, there is simply no reason to deal with the devel
repository.  And speaking from experience, when someone starts dealing
with Emacs, they are very likely to just copy random code off blogs and
fora until something appears to work.  Having development versions of
ELPA advertised with ready-to-copy code will just break stuff.  I guess
mentioning it doesn't inherently pose an issue.  Either way, the reason
I am interested in seeing GNU and NonGNU ELPA is that this incentives
stable package releases as the default mode of operation, so that is
where I am coming from with this line of argumentation.

-- 
        Philip Kaludercic