access to ELPA development packages?

access to ELPA development packages?

[Stephen Leake]

When non-gnu ELPA was introduced, I believe Stefan also made available
devel/alpha versions of the gnu and non-gnu packages; the ELPA server
packages the current head in each package, rather than the last version
change.

However, I can't find any docs on how to access that; I looked in the
Gnu ELPA README, and searched this mailing list archive (never a satisfying
experience).

I'd like to use that now; I'm finishing a new ada-mode release, and I'd
like to have some community members alpha test it before the final
release.

Is that still supported? Can we put instructions for accessing it on
the ELPA home webpage, or in elpa/admin/README? I'm not clear how to
edit the ELPA home webpage.

-- 
-- Stephe

Re: access to ELPA development packages?

[Stephen Leake]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> When non-gnu ELPA was introduced, I believe Stefan also made available
> devel/alpha versions of the gnu and non-gnu packages; the ELPA server
> packages the current head in each package, rather than the last version
> change.
>
> However, I can't find any docs on how to access that; I looked in the
> Gnu ELPA README, and searched this mailing list archive (never a satisfying
> experience).

This part I figured out:

(add-to-list 'package-archives (cons "gnu-devel" "https://elpa.gnu.org/devel"))

> Can we put instructions for accessing it on
> the ELPA home webpage, or in elpa/admin/README? I'm not clear how to
> edit the ELPA home webpage.

I think we should do this.

-- 
-- Stephe

Re: access to ELPA development packages?

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 1090 bytes --]

So, this gnu-devel repo is in essence something similar to MELPA, right? I agree that it'd be nice if was publicized a bit more (I had never heard of it until now), so packages can get more testing during their development cycles. 

On Thu, Jul 22, 2021, at 4:17 PM, Stephen Leake wrote:
> Stephen Leake <stephen_leake@stephe-leake.org> writes:
> 
> > When non-gnu ELPA was introduced, I believe Stefan also made available
> > devel/alpha versions of the gnu and non-gnu packages; the ELPA server
> > packages the current head in each package, rather than the last version
> > change.
> >
> > However, I can't find any docs on how to access that; I looked in the
> > Gnu ELPA README, and searched this mailing list archive (never a satisfying
> > experience).
> 
> This part I figured out:
> 
> (add-to-list 'package-archives (cons "gnu-devel" "https://elpa.gnu.org/devel"))
> 
> > Can we put instructions for accessing it on
> > the ELPA home webpage, or in elpa/admin/README? I'm not clear how to
> > edit the ELPA home webpage.
> 
> I think we should do this.
> 
> -- 
> -- Stephe
> 
> 

[-- Attachment #2: Type: text/html, Size: 1775 bytes --]

Re: access to ELPA development packages?

[Philip Kaludercic]

"Bozhidar Batsov" <bozhidar@batsov.dev> writes:

> So, this gnu-devel repo is in essence something similar to MELPA,
> right? I agree that it'd be nice if was publicized a bit more (I had
> never heard of it until now), so packages can get more testing during
> their development cycles.

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.

-- 
	Philip Kaludercic

Re: access to ELPA development packages?

[Dmitry Gutov]

On 23.07.2021 14:04, Philip Kaludercic wrote:
> 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.

FWIW, it has a saner versioning policy (similar to what has been 
discussed for MELPA in the past), so that removes some of the same issues.

Re: access to ELPA development packages?

[Richard Stallman]

[[[ 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?
-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

Re: access to ELPA development packages?

[dick]

You've explained this poorly, and at too esoteric a level of detail.

Donning my anti-flak jacket in preparation for RMS's justifiable indignation
at my having spoken for his eminence, RMS is more concerned about the public's
conflation of MELPA with GNU, the former having accrued enough name
recognition over the years to become metonymous with the emacs community despite
flouting FSF doctrine.

The MELPA versioning deficiencies are irksome yes, but in no way deleterious
to MELPA's popularity or basic function, which is two-fold, to provide a
package archive unconstrained by FSF doctrine, and to feed our narcissism as
programmers.  To expand on the latter, more than ninety percent of the
packages hosted on MELPA are pet projects of dubious practical value.

To those ends, MELPA provides real value, the objections of ideologues notwithstanding.

Re: access to ELPA development packages?

[Philip Kaludercic]

dick <dick.r.chiang@gmail.com> writes:

> You've explained this poorly, and at too esoteric a level of detail.
>
> Donning my anti-flak jacket in preparation for RMS's justifiable indignation
> at my having spoken for his eminence, RMS is more concerned about the public's
> conflation of MELPA with GNU, the former having accrued enough name
> recognition over the years to become metonymous with the emacs community despite
> flouting FSF doctrine.

> The MELPA versioning deficiencies are irksome yes, but in no way deleterious
> to MELPA's popularity or basic function, which is two-fold, to provide a
> package archive unconstrained by FSF doctrine, and to feed our narcissism as
> programmers.  To expand on the latter, more than ninety percent of the
> packages hosted on MELPA are pet projects of dubious practical value.
>
> To those ends, MELPA provides real value, the objections of ideologues notwithstanding.

My issues with MELPA are not ideological. I know that they have non-free
adjacent software and a lot of weird stuff -- and good stuff too -- but
I am really just conceder with MELPA "unstable" being the default
repository a lot of people use.

-- 
	Philip Kaludercic

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

Re: access to ELPA development packages?

[Stefan Monnier]

> Is that still supported? Can we put instructions for accessing it on
> the ELPA home webpage, or in elpa/admin/README? I'm not clear how to
> edit the ELPA home webpage.

Feel free to send me patches against the HTML of https://elpa.(non)gnu.org/.
I don't think it belongs in elpa/admin/README but it could be added to
elpa/README if you think it's beneficial.

I do think it would be good to improve it so it mentions the `devel`
version (and so the gnu/nongnu points to the nongnu/gno one).

It'd also make sense for the pages like

    https://elpa.gnu.org/packages/ada-mode.html

to include a link to the corresponding `devel` page (and vice-versa).
Theses pages are generated by elpa/admin/elpa-admin.el.

[ I also suspect that these pages would benefit from a slight redesign
  so that the description+latest+maintainer+homepage+browselink+badge
  takes up less vertical space.  IIUC this can be done by changing the
  CSS, so send me diffs against the CSS file for that.  ]


        Stefan

Re: access to ELPA development packages?

[Yuan Fu]

> 
> [ I also suspect that these pages would benefit from a slight redesign
>  so that the description+latest+maintainer+homepage+browselink+badge
>  takes up less vertical space.  IIUC this can be done by changing the
>  CSS, so send me diffs against the CSS file for that.  ]

No patch, but you could go to layout.css:151 and remove "margin-bottom: 10px;”.

Yuan

Re: access to ELPA development packages?

[Stefan Monnier]

Yuan Fu [2021-07-26 16:34:03] wrote:
>> [ I also suspect that these pages would benefit from a slight redesign
>>  so that the description+latest+maintainer+homepage+browselink+badge
>>  takes up less vertical space.  IIUC this can be done by changing the
>>  CSS, so send me diffs against the CSS file for that.  ]
> No patch, but you could go to layout.css:151 and remove "margin-bottom: 10px;”.

Looks OK, thanks, installed,


        Stefan

Re: access to ELPA development packages?

[Stephen Leake]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Is that still supported? Can we put instructions for accessing it on
>> the ELPA home webpage, or in elpa/admin/README? I'm not clear how to
>> edit the ELPA home webpage.
>
> Feel free to send me patches against the HTML of https://elpa.(non)gnu.org/.
> I don't think it belongs in elpa/admin/README but it could be added to
> elpa/README if you think it's beneficial.

I propose this paragraph in elpa/README under the "** Notes specific to
=elpa.gnu.org=" node:

```org
*** Release and devel archives
elpa.gnu.org serves the gnu and nongnu package collections (roughly,
gnu requires FSF copyright assign, nongnu doesn't, but these terms are
not fully defined here).

In addition, elpa.gnu.org serves release and devel versions of each
package. The release version is defined by a change in the =Version:=
header of a package; the devel version is the latest commit.

The release version is accessed at:

gnu    - https://elpa.gnu.org/packages/
nongnu - https://elpa.nongnu.org/nongnu/

The devel version is accessed at:

gnu    - https://elpa.gnu.org/devel
nongnu - 
'''

What is the URL for nongnu devel (I could not find it via a web search)?

-- 
-- Stephe

Re: access to ELPA development packages?

[Basil L. Contovounesios]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> The release version is accessed at:
>
> gnu    - https://elpa.gnu.org/packages/
> nongnu - https://elpa.nongnu.org/nongnu/
>
> The devel version is accessed at:
>
> gnu    - https://elpa.gnu.org/devel
> nongnu - 
> '''
>
> What is the URL for nongnu devel (I could not find it via a web search)?

https://elpa.nongnu.org/nongnu-devel/

Thanks,

-- 
Basil

Re: access to ELPA development packages?

[Richard Stallman]

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

  > The release version is accessed at:

  > gnu    - https://elpa.gnu.org/packages/
  > nongnu - https://elpa.nongnu.org/nongnu/

  > The devel version is accessed at:

  > gnu    - https://elpa.gnu.org/devel
  > nongnu - 

It's ok to add those three URLs.  But since the intention
is to list also a URL for devel of nongnu ELPA, please wait.
I have to have a conversation with the maintainers
to make sure we aren't making a mistake with that one.

I'll start that today.

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

Re: access to ELPA development packages?

[Richard Stallman]

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

  > The release version is accessed at:

  > gnu    - https://elpa.gnu.org/packages/
  > nongnu - https://elpa.nongnu.org/nongnu/

  > The devel version is accessed at:

  > gnu    - https://elpa.gnu.org/devel
  > nongnu - 

It's ok to add those three URLs.  But since the intention
is to list also a URL for nongnu devel, please wait.
I have to have a conversation with the maintainers
to make sure we aren't making a mistake with that one.

I'll start that today.

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

Re: access to ELPA development packages?

[Richard Stallman]

[[[ 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'd like to use that now; I'm finishing a new ada-mode release, and I'd
  > like to have some community members alpha test it before the final
  > release.

Perhaps we should make test versions available only temporarily, so
that nobody goes on for years referring to a momentary test version.
We should tell people that we will delete the test version
once the new code has been installed in the Emacs repo,
and we should actually do that.

Or, what would you think of putting this in a branch in the Emacs repo?

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