[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: access to ELPA development packages?
Re: access to ELPA development packages?
Mon, 26 Jul 2021 22:53:09 -0700
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (windows-nt)
Philip Kaludercic <firstname.lastname@example.org> writes:
> Richard Stallman <email@example.com> 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.
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.
Re: access to ELPA development packages?, Stefan Monnier, 2021/07/23
Re: access to ELPA development packages?, Richard Stallman, 2021/07/27
- access to ELPA development packages?, Stephen Leake, 2021/07/21
- Re: access to ELPA development packages?, Stephen Leake, 2021/07/22
- Re: access to ELPA development packages?, Bozhidar Batsov, 2021/07/23
- Re: access to ELPA development packages?, Philip Kaludercic, 2021/07/23
- Re: access to ELPA development packages?, Dmitry Gutov, 2021/07/23
- Re: access to ELPA development packages?, Richard Stallman, 2021/07/25
- Re: access to ELPA development packages?, Philip Kaludercic, 2021/07/26
- Re: access to ELPA development packages?, dick, 2021/07/26
- Re: access to ELPA development packages?, Philip Kaludercic, 2021/07/27
- Re: access to ELPA development packages?,
Stephen Leake <=