Re: access to ELPA development packages?

[Stephen Leake]

Philip Kaludercic <philipk@posteo.net> writes:

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

+1

To be clear, the only reason I want to use ELPA devel is for a
pre-release test of a new version of ada-mode, without disturbing the
release version. The version I push to ELPA devel from upstream has
passed all my tests, I just want some users to test it.

The documentation of how to access ELPA devel should make clear
that this (or something similar) is the prefered use.

--
-- Stephe