From: Stephen Leake <stephen_leake@stephe-leake.org>
To: Philip Kaludercic <philipk@posteo.net>
Cc: bozhidar@batsov.dev, Richard Stallman <rms@gnu.org>, emacs-devel@gnu.org
Subject: Re: access to ELPA development packages?
Date: Mon, 26 Jul 2021 22:53:09 -0700 [thread overview]
Message-ID: <86k0lc5mm2.fsf@stephe-leake.org> (raw)
In-Reply-To: <87im0wztl6.fsf@posteo.net> (Philip Kaludercic's message of "Mon, 26 Jul 2021 20:52:05 +0000")
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
next prev parent reply other threads:[~2021-07-27 5:53 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-22 0:23 access to ELPA development packages? Stephen Leake
2021-07-22 13:17 ` Stephen Leake
2021-07-23 6:26 ` Bozhidar Batsov
2021-07-23 11:04 ` Philip Kaludercic
2021-07-23 11:42 ` Dmitry Gutov
2021-07-26 0:16 ` Richard Stallman
2021-07-26 20:52 ` Philip Kaludercic
2021-07-26 22:01 ` dick
2021-07-27 8:12 ` Philip Kaludercic
2021-07-27 5:53 ` Stephen Leake [this message]
2021-07-23 15:14 ` Stefan Monnier
2021-07-26 20:34 ` Yuan Fu
2021-08-03 22:17 ` Stefan Monnier
2021-07-31 7:08 ` Stephen Leake
2021-07-31 11:21 ` Basil L. Contovounesios
2021-08-01 7:49 ` Richard Stallman
2021-08-02 1:06 ` Richard Stallman
2021-07-28 1:01 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86k0lc5mm2.fsf@stephe-leake.org \
--to=stephen_leake@stephe-leake.org \
--cc=bozhidar@batsov.dev \
--cc=emacs-devel@gnu.org \
--cc=philipk@posteo.net \
--cc=rms@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).