NonGNU ELPA

NonGNU ELPA

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

No progress is happening on NonGNU ELPA.  We need someone who would
like to implement it.  Would someone like to do that?

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

Re: NonGNU ELPA

[Tim Van den Langenbergh]

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

On Friday, 11 September 2020 06:21:20 CEST Richard Stallman wrote:
> [[[ 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. ]]]
>
> No progress is happening on NonGNU ELPA.  We need someone who would
> like to implement it.  Would someone like to do that?
>
>

For other interested parties:
I seem to remember there being discussion about NonGNU ELPA needing a
repository system. Would it be sufficient to use git submodules for packages
that are in git source control and basic shell scripts for packages distributed
through Emacs Wiki?

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: NonGNU ELPA

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

  > repository system. Would it be sufficient to use git submodules
  > for packages that are in git source control and basic shell
  > scripts for packages distributed through Emacs Wiki?

Here's the general plan.

    The basic idea is to set up a site for distribution of packages.
    It will not host development -- rather, each package will be developed
    somewhere else.  We should have a system to copy the package sources
    automatically from somewhere else.  What exactly it should do
    is one of the questions that needs deciding.

    Sometimes "somewhere else" will be the repo used by the package developers.
    We can do that when the developers are cooperating with us and we
    have confidence in them.

    Sometimes it will be a repo we set up on Savannah.  We will do this
    when (1) the developers cooperate with us and would like us to provide
    a repo to use, (2) the developers don't cooperate with us and we must
    not release their changes without checking them, or (3) we make our
    own changes in the package.  In cases of type (1), we will be able to
    give write access to each package to the developers of that package.

I don't know what git submodules do.  Maybe we could get the job done
using them, but I have the feeling it would be kludgy.

I know what shell scripts are but "basic shell scripts" doesn't
describe a method.  It seems reckless to mirror code from a wiki.


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

Re: NonGNU ELPA

[Göktuğ Kayaalp]

On 2020-09-14 06:50 +03, Richard Stallman <rms@gnu.org> wrote:
> Here's the general plan.
[... snip ...]

Wouldn’t this be just another MELPA, essentially?

-- 
İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: NonGNU ELPA

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

  > Wouldn’t this be just another MELPA, essentially?

Nothing like it.  We will decide which packages to put in
NonGNU ELPA, and we can modify the code if necessary.

THe plan was published here a few weeks ago.

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

Re: NonGNU ELPA

[Mingde (Matthew) Zeng]

>   > Wouldn’t this be just another MELPA, essentially?
>
> Nothing like it.  We will decide which packages to put in
> NonGNU ELPA, and we can modify the code if necessary.

Is the modification going to be sent to package upstream as well? If yes, what if the package author doesn't like the changes?

>
> THe plan was published here a few weeks ago.

Link to the plan to save people time searching for it: https://lists.gnu.org/archive/html/emacs-devel/2020-08/msg00152.html

I see how it differs from MELPA, but I still don't quite understand why would an user want to use this instead of MELPA, which is more popular, less strict than ELPA and doesn't require a copyright assignment.


--
Mingde (Matthew) Zeng

Re: NonGNU ELPA

[Vasilij Schneidermann]

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

> I see how it differs from MELPA, but I still don't quite understand
> why would an user want to use this instead of MELPA, which is more
> popular, less strict than ELPA and doesn't require a copyright
> assignment.

There won't be a copyright assignment part, see the original proposal
you've linked to.  However the package will still need to adhere to
certain rules to ensure the user freedoms, something that far from all
MELPA packages do.

Vasilij

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: NonGNU ELPA

[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 see how it differs from MELPA, but I still don't quite
  > understand why would an user want to use this instead of MELPA,

One reason is that Emacs will inform users about NonGNU ELPA
and encourage their use of it.

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

Re: NonGNU ELPA

[Thomas Fitzsimmons]

Hi,

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. ]]]
>
>   > Wouldn’t this be just another MELPA, essentially?
>
> Nothing like it.  We will decide which packages to put in
> NonGNU ELPA, and we can modify the code if necessary.
>
> THe plan was published here a few weeks ago.

The published plan doesn't mention: will NonGNU ELPA archive(s) be
included in the package-archives variable by default?

Thomas

Re: NonGNU ELPA

[Stefan Monnier]

> Will NonGNU ELPA archive(s) be included in the package-archives
> variable by default?

Yes, that's the whole point ;-)


        Stefan

Re: NonGNU ELPA

[Thomas Fitzsimmons]

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

>> Will NonGNU ELPA archive(s) be included in the package-archives
>> variable by default?
>
> Yes, that's the whole point ;-)

Yeah, I assumed so; I just found it strange that the published plan
didn't mention this prominently, since this is a user-visible advantage
of NonGNU ELPA vs MELPA -- that it doesn't require package-archives
fiddling prior to installing the packages it provides.

Thomas

NonGNU ELPA and release frequency

[Antoine Kalmbach]

Given that the details of NonGNU ELPA are still being fleshed out, has
there been any discussion on how often NonGNU ELPA packages are
released into the package repository?

Suppose I am a package author upstream on a package that isn't in GNU
ELPA.  This package is maintained in an external repository somewhere on
the net.  I release a new version, pushing the commit into the
repository.  Now the following things are unclear:

  1. If I want my changes to appear in NonGNU ELPA, should I:

     a. Send a patch with the changes to the appropriate mailing lists
        (emacs-devel or bug-gnu-emacs?)
     b. Send a request to pull the changes to ibid.
     c. Push changes to some reference
     d. Email a mailing list announcing the changes and wait for someone
        to update the package

  2. How often would NonGNU packages be updated? Will it be up to each
     individual package, or would there be recurring (e.g. monthly)
     "distributions" of the whole package set, so that a package and all
     its dependents would effectively be "frozen" until a regular
     update?

  3. Would NonGNU ELPA have some sort of automated build system for
     checking that packages meet some sort of quality checks, for
     instance, checking that packages can be byte compiled without
     errors, checking documentation using checkdoc, and verifying the
     license is appropriate, etc.

Do any of those questions make sense? Lately on several forums there has
been much discussion about MELPA and other third-party repositories, and
the nature of those discussions strongly indicates that NonGNU ELPA is
necessary and requires attention.

-- 
Antoine Kalmbach

Re: NonGNU ELPA and release frequency

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

  > Given that the details of NonGNU ELPA are still being fleshed out, has
  > there been any discussion on how often NonGNU ELPA packages are
  > released into the package repository?

That is not a meaningful question.  There is no place in the plan
for the sort of schedule that those words imply.

NonGNU ELPA would contain many packages, each managed in its own way.
Whoever has charge of any given package for NonGNU ELPA purposes will
be able to operate on it at any time.

    > 1. If I want my changes to appear in NonGNU ELPA, should I:

Your changes would be in some package.  The answer would depend on how
we are handling that package for NonGNU ELPA and what your
relationship to it is.

    > 3. Would NonGNU ELPA have some sort of automated build system for
    >    checking that packages meet some sort of quality checks, for
    >    instance, checking that packages can be byte compiled without
    >    errors, checking documentation using checkdoc, and verifying the
    >    license is appropriate, etc.

This remains to be decided.  We don't need to think about this
just for setting up NonGNU ELPA.

We would like people to volunteer to start setting it up.

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

Re: NonGNU ELPA and release frequency

[Jean Louis]

My proposals for plan of action for ELPA on nongnu.org are following,
and they are not in any order:

- [ ] establish goals purposes for non-GNU ELPA.

  My proposal for purpose is to provide useful GNU Emacs packages as
  free software meant for inclusion into fully free and FSF endorsed
  free system distributions. Guidelines for free software system
  distributions on
  https://www.gnu.org/distros/free-system-distribution-guidelines.html
  should apply for non-GNU ELPA and for GNU ELPA as well.

- [ ] set up the mailing list for non GNU ELPA. My proposal would be:
  nongnu-elpa-devel@nongnu.org as maybe it would be good not to mix it
  with emacs-devel

- [ ] Find contact information of many developers and invite
  developers personally to contribute their packages, they can start
  contributing already by using the mailing list and collaborating
  with others.

- [ ] discuss the set of policies or principles for non-GNU ELPA. For
  example do we really want to see Python packages wrapped inside of
  the GNU Emacs package? I don't. 

- [ ] obtain server space for hosting of a website

- [ ] decide on sub domain or URL, it could for example
  https://elpa.nongnu.org

- [ ] replicate GNU ELPA website in similar fashon on ELPA on
  nongnu.org without changing much, keep informing public on the
  website of the project's progress

- [ ] provide hosting and shell access to set up git and free code
  hosting platform familiar to many developers using Github. Such free
  code hosting platform is https://gitea.io/en-us/ or Gitlab.com, I
  would prefer first. It looks similar to Github, look here:
  https://gitea.com/gitea/gitea-vet and there is problem with one
  Javascript, they have to be asked to publish the license properly.

- [ ] install such git hosting, install Gitea or Gitlab or other web based
  git whatever be decided as best

- [ ] use already made software for GNU ELPA to develop in same
  fashion for elpa.nongnu.org, as not to change drastically well
  established workflows

- [ ] propose improvements to workflows both on GNU ELPA and non-GNU
  ELPA, and collaborate with emacs-devel
  
- [ ] start distributing few packages, and keep including other
  packages

- [ ] when time seem right, include the package repository
  specification in GNU Emacs

- [ ] welcome and invite developers to switch to free hosting at
  nongnu.org

- [ ] welcome and invite developers to contribute their packages to
  GNU ELPA and transition their package. Futurem may become blended.

- [ ] keep doing all well established actions just as GNU ELPA is
  doing to provide more free software for purpose of expansion of
  fully free operating systems.

- [ ] add additional scripts or support to help various other
  GNU/Linux distributions to easily package both GNU ELPA and non-GNU
  ELPA packages

Jean

Re: NonGNU ELPA and release frequency

[Eli Zaretskii]

> Date: Sat, 24 Oct 2020 10:08:04 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: Antoine Kalmbach <ane@iki.fi>, emacs-devel@gnu.org
> 
> My proposals for plan of action for ELPA on nongnu.org are following,
> and they are not in any order:

Would you like to volunteer to do some or all of this?

Some of what you mention was already done, look in the past
discussions here.  Examples:

> - [ ] establish goals purposes for non-GNU ELPA.

Done.

> - [ ] discuss the set of policies or principles for non-GNU ELPA.

Done.

>   For example do we really want to see Python packages wrapped
>   inside of the GNU Emacs package? I don't.

That's not policy, those are very low-level details.  (And I don't see
why Python should not be allowed.)

> - [ ] decide on sub domain or URL, it could for example
>   https://elpa.nongnu.org

Already done.

> - [ ] replicate GNU ELPA website in similar fashon on ELPA on
>   nongnu.org without changing much, keep informing public on the
>   website of the project's progress

Already decided.

Re: NonGNU ELPA and release frequency

[Jean Louis]

On Sat, Oct 24, 2020 at 11:41:47AM +0300, Eli Zaretskii wrote:
> > Date: Sat, 24 Oct 2020 10:08:04 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: Antoine Kalmbach <ane@iki.fi>, emacs-devel@gnu.org
> > 
> > My proposals for plan of action for ELPA on nongnu.org are following,
> > and they are not in any order:
> 
> Would you like to volunteer to do some or all of this?

I am ready.

Re: NonGNU ELPA and release frequency

[Eli Zaretskii]

> Date: Sat, 24 Oct 2020 05:06:25 -0700
> From: Jean Louis <bugs@rcdrun.com>
> Cc: rms@gnu.org, ane@iki.fi, emacs-devel@gnu.org
> 
> On Sat, Oct 24, 2020 at 11:41:47AM +0300, Eli Zaretskii wrote:
> > > Date: Sat, 24 Oct 2020 10:08:04 +0300
> > > From: Jean Louis <bugs@gnu.support>
> > > Cc: Antoine Kalmbach <ane@iki.fi>, emacs-devel@gnu.org
> > > 
> > > My proposals for plan of action for ELPA on nongnu.org are following,
> > > and they are not in any order:
> > 
> > Would you like to volunteer to do some or all of this?
> 
> I am ready.

Thank you; please go ahead.

Re: NonGNU ELPA and release frequency

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-10-24 15:55]:
> > Date: Sat, 24 Oct 2020 05:06:25 -0700
> > From: Jean Louis <bugs@rcdrun.com>
> > Cc: rms@gnu.org, ane@iki.fi, emacs-devel@gnu.org
> > 
> > On Sat, Oct 24, 2020 at 11:41:47AM +0300, Eli Zaretskii wrote:
> > > > Date: Sat, 24 Oct 2020 10:08:04 +0300
> > > > From: Jean Louis <bugs@gnu.support>
> > > > Cc: Antoine Kalmbach <ane@iki.fi>, emacs-devel@gnu.org
> > > > 
> > > > My proposals for plan of action for ELPA on nongnu.org are following,
> > > > and they are not in any order:
> > > 
> > > Would you like to volunteer to do some or all of this?
> > 
> > I am ready.
> 
> Thank you; please go ahead.

Tell me next steps.

On my side I am already making my personal review of packages and
making list of those wrapping non-free packages, and sorting them,
looking inside, compiling and looking which are useful. I will come up
with my list soon.

So far there is about 20 that are made for non-free software or that
would drive users to non-free, but I have just started reviewing it.

Re: NonGNU ELPA and release frequency

[Eli Zaretskii]

> Date: Sat, 24 Oct 2020 17:12:13 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: rms@gnu.org, ane@iki.fi, emacs-devel@gnu.org
> 
> > > > Would you like to volunteer to do some or all of this?
> > > 
> > > I am ready.
> > 
> > Thank you; please go ahead.
> 
> Tell me next steps.

You had it all in your list of the tasks to be done, I think.  Just
pick up one of them, preferably near the beginning, and start working
on it.  When it's done, continue to the next one in the list.

We are here to help if you have questions.

> On my side I am already making my personal review of packages and
> making list of those wrapping non-free packages, and sorting them,
> looking inside, compiling and looking which are useful. I will come up
> with my list soon.
> 
> So far there is about 20 that are made for non-free software or that
> would drive users to non-free, but I have just started reviewing it.

Thanks, but I think the steps that set up the infrastructure should
come first.  We already have a few packages we know we'd like to have
there, so once the repository is ready, it won't be left empty for
long.

Re: NonGNU ELPA

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-10-24 17:17]:
> You had it all in your list of the tasks to be done, I think.  Just
> pick up one of them, preferably near the beginning, and start working
> on it.  When it's done, continue to the next one in the list.

My proposal is to have separate mailing list, I am not admin for
that. Is that fine to set, what do you think?

> Thanks, but I think the steps that set up the infrastructure should
> come first.  We already have a few packages we know we'd like to have
> there, so once the repository is ready, it won't be left empty for
> long.

Alright. When?

And which sub-domain or URL is destined for non-GNU ELPA? Is it maybe
elpa.nongnu.org ?

Re: NonGNU ELPA

[Eli Zaretskii]

> Date: Sat, 24 Oct 2020 17:21:38 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: rms@gnu.org, ane@iki.fi, emacs-devel@gnu.org
> 
> * Eli Zaretskii <eliz@gnu.org> [2020-10-24 17:17]:
> > You had it all in your list of the tasks to be done, I think.  Just
> > pick up one of them, preferably near the beginning, and start working
> > on it.  When it's done, continue to the next one in the list.
> 
> My proposal is to have separate mailing list, I am not admin for
> that. Is that fine to set, what do you think?

I don't think a separate mailing list is necessary at this time.
Let's see if the traffic related to this repository becomes
significant, and decide then.

> > Thanks, but I think the steps that set up the infrastructure should
> > come first.  We already have a few packages we know we'd like to have
> > there, so once the repository is ready, it won't be left empty for
> > long.
> 
> Alright. When?

Now?

> And which sub-domain or URL is destined for non-GNU ELPA? Is it maybe
> elpa.nongnu.org ?

Yes, I think that's what we wanted.

Re: NonGNU ELPA and release frequency

[Antoine Kalmbach]

Jean Louis <bugs@gnu.support> writes:

> - [ ] provide hosting and shell access to set up git and free code
>   hosting platform familiar to many developers using Github. Such free
>   code hosting platform is https://gitea.io/en-us/ or Gitlab.com, I
>   would prefer first. It looks similar to Github, look here:
>   https://gitea.com/gitea/gitea-vet and there is problem with one
>   Javascript, they have to be asked to publish the license properly.
>
> - [ ] install such git hosting, install Gitea or Gitlab or other web based
>   git whatever be decided as best
>

Is providing hosting necessary at this point? GNU already offers
Savannah. I think offering hosting in general is a good idea, but I am
wondering if this is necessary to get user traction for NonGNU ELPA. At
the very least, we should look at the infrastructure issues first.

GNU seems to be running Gitlab already at http://emba.gnu.org. It is
used to run CI tests for Emacs. I think it would be a good idea for
NonGNU ELPA (and ELPA as well) to have CI tests that do the following:

  * Run checkdoc on all files in the package
  * Try running `package-install-file' on every one of them
    (dependencies towards other (Non)GNU ELPA need to be figured out -
    if package A depends on B, we must run those tests first on B, etc.)
  * [NonGNU ELPA only] If package-lint[1] can be added to NonGNU ELPA
    that can also be run on the files

That way with running CI jobs we would make sure all packages there
work. That is, they work in the sense that `M-x package-install'ing them
will work.

Perhaps the Gitlab instance used at emba.gnu.org could also be used for
(Non)GNU ELPA CI tests at some point?

[1] https://github.com/purcell/package-lint

-- 
Antoine Kalmbach

Re: NonGNU ELPA

[Jean Louis]

* Antoine Kalmbach <ane@iki.fi> [2020-10-24 17:25]:
> Is providing hosting necessary at this point? GNU already offers
> Savannah.

That is what I meant.

And Gitlab or Gitea is convenient, and if such exists already it is
good. But that one responds on gnu.org domain, so people could mistake
it for being GNU software, which those packages are not yet.

-- 
Jean Louis

Re: NonGNU ELPA

[Antoine Kalmbach]

Jean Louis <bugs@gnu.support> writes:

> And Gitlab or Gitea is convenient, and if such exists already it is
> good. But that one responds on gnu.org domain, so people could mistake
> it for being GNU software, which those packages are not yet.

Ah, I only propose using the emba.gnu.org instance for CI tests, not
for hosting packages. The CI runs are just something that runs to verify
each update to (non)gnu elpa does not introduce broken pacakges. But this
Gitlab instance, due to the reason you state, is not suitable for
hosting non-GNU packages.

-- 
Antoine Kalmbach

Re: NonGNU ELPA

[Michael Albinus]

Antoine Kalmbach <ane@iki.fi> writes:

> Ah, I only propose using the emba.gnu.org instance for CI tests, not
> for hosting packages. The CI runs are just something that runs to verify
> each update to (non)gnu elpa does not introduce broken pacakges. But this
> Gitlab instance, due to the reason you state, is not suitable for
> hosting non-GNU packages.

An emba.nongnu.org gitlab instance (or whatever name) could be settled
up easily. The more interesting task it what to run in its CI.

Maybe we start with the CI for GNU ELPA on emba.gnu.org? I expect to run
very similar tasks for GNU ELPA and NonGNU ELPA. Could you show a
respective .gitlab-ci.yml?

Best regards, Michael.

Re: NonGNU ELPA

[Stefan Kangas]

Michael Albinus <michael.albinus@gmx.de> writes:

> Maybe we start with the CI for GNU ELPA on emba.gnu.org? I expect to run
> very similar tasks for GNU ELPA and NonGNU ELPA.

Indeed.  It would be good if someone could start implementing this.

Re: NonGNU ELPA

[Antoine Kalmbach]

Stefan Kangas <stefankangas@gmail.com> writes:

>> Maybe we start with the CI for GNU ELPA on emba.gnu.org? I expect to run
>> very similar tasks for GNU ELPA and NonGNU ELPA.
>
> Indeed.  It would be good if someone could start implementing this.

I think the gist of the ELPA CI would be something like:

  1. Clone the repository and emacs.git
  2. Build the package archive

These steps already have automation in place, since that's what is done
for building the ELPA index. Then, for the CI run,

  3. Start a batch Emacs instance and replace `package-archives' with
     (("elpa-test" . "/path/to/built/archive")) where that path points
     to the built package archive in step 2.

  4. Loop through each package and run `package-install` on it. 
  5. Optionally run also some linters etc., like checkdoc.

The good part about this is that it's essentially just taking existing
automation one step further, i.e. verifying each package in the
repository can actually be installed.  I have no idea what's going to
happen with cyclic dependencies though.  I suppose package.el can handle
all that.

-- 
Antoine Kalmbach

Re: NonGNU ELPA

[Michael Albinus]

Antoine Kalmbach <ane@iki.fi> writes:

Hi Antoine,

> I think the gist of the ELPA CI would be something like:
>
>   1. Clone the repository and emacs.git

Well, emacs.git is already cloned and compiled on emba.gnu.org
regularly. I guess we could use the artifacts of such a build for a
running Emacs.

And this step shall also take into account the external packages.

>   2. Build the package archive

Depends how it is called. If it is called for every push to the elpa
repository, it might not be wise to build always a whole archive. Just
the package in question shall be built.

> These steps already have automation in place, since that's what is done
> for building the ELPA index. Then, for the CI run,
>
>   3. Start a batch Emacs instance and replace `package-archives' with
>      (("elpa-test" . "/path/to/built/archive")) where that path points
>      to the built package archive in step 2.

The GNUmakefile knows already the target archive.

>   4. Loop through each package and run `package-install` on it.

Or do it for the package in question.

>   5. Optionally run also some linters etc., like checkdoc.

Yep. Some packages come with ERT tests, they could run.

> The good part about this is that it's essentially just taking existing
> automation one step further, i.e. verifying each package in the
> repository can actually be installed.  I have no idea what's going to
> happen with cyclic dependencies though.  I suppose package.el can handle
> all that.

Could you write an initial .gitlab-ci.yml? You might look at the
respective file in the Emacs repo (which also needs some improvements).

Thanks, and best regards, Michael.

Re: NonGNU ELPA

[Michael Albinus]

Michael Albinus <michael.albinus@gmx.de> writes:

Hi Antoine,

> Could you write an initial .gitlab-ci.yml? You might look at the
> respective file in the Emacs repo (which also needs some improvements).

Sorry to urge you. This thread is about NonGNU ELPA, and I don't know
whether you intend to sign FSF legal papers.

Best regards, Michael.

Re: NonGNU ELPA

[Antoine Kalmbach]

Michael Albinus <michael.albinus@gmx.de> writes:

>> Could you write an initial .gitlab-ci.yml? You might look at the
>> respective file in the Emacs repo (which also needs some improvements).
>
> Sorry to urge you. This thread is about NonGNU ELPA, and I don't know
> whether you intend to sign FSF legal papers.
>
> Best regards, Michael.

Paperwork is in progress, awaiting countersignature from FSF. I think it
will be done next week.

I'll try to have try at the .gitlab-ci.yml soon..ish.

-- 
Antoine Kalmbach

Re: NonGNU ELPA and release frequency

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

  > - [ ] replicate GNU ELPA website in similar fashon on ELPA on
  >   nongnu.org without changing much, keep informing public on the
  >   website of the project's progress

Maybe that would be a good way to start, but
we don't want NonGNU ELPA to work like GNU ELPA.

  > - [ ] provide hosting and shell access to set up git and free code
  >   hosting platform familiar to many developers using Github. Such free
  >   code hosting platform is https://gitea.io/en-us/ or Gitlab.com, I
  >   would prefer first.

One of the inconveniences with GNU ELPA is that it is a single repo.
Everyone who maintains a package in GNU ELPA needs write-access to the
whole repo.

In NonGNU ELPA, we want each package to have, effectively, its own
repo.  We want to distribute all the packages from a single place in
one single way, but no packages will be developed _in_ that place.
Each package will be developed in a repo somewhere else.  Some will be
on Savannah.  Some will be elsewhere (but insisting that maintenance
not require running nonfree JS code).

The Emacs maintainers will have full control over the NonGNU ELPA
web site, including deciding which packages to distribute, and
which repo to get each package from.

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

Re: NonGNU ELPA and release frequency

[Ivan Yonchovski]

Richard Stallman writes:

> Each package will be developed in a repo somewhere else.  Some will be
> on Savannah.  Some will be elsewhere (but insisting that maintenance
> not require running nonfree JS code).

So, if someone wants to be in NonGNU elpa should not be using github? If
this is the case then why it is fine for ELPA package to be in github
but it won't be fine for NonGNU ELPA?

Thanks,
Ivan

Re: NonGNU ELPA and release frequency

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

  > So, if someone wants to be in NonGNU elpa should not be using github? If
  > this is the case then why it is fine for ELPA package to be in github
  > but it won't be fine for NonGNU ELPA?

I haven't come to a conclusion about that.  I see a few possibilities.

* If the Emacs maintainers who work on this package have Github accounts,
in principle we could deal with it on GitHub.

* We could make a repo on Savannah that has a more-or-less copy of the
GitHub repo, and our maintainers could when necessary make their
changes there.

It depends on whether the package maintainer is cooperating with us.
If so, the first option is possible.  If not, we would certainly do
the latter.

One question is, when we need to make our own changes in a package,
should we do those changes in NonGNU ELPA's repo itself,
or should we make a separate Savannah repo for our version of the package
so that NonGNU ELPA's is never anything but a mirror?

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

Re: NonGNU ELPA

[Jean Louis]

* Richard Stallman <rms@gnu.org> [2020-10-26 07:11]:
> One question is, when we need to make our own changes in a package,
> should we do those changes in NonGNU ELPA's repo itself,
> or should we make a separate Savannah repo for our version of the package
> so that NonGNU ELPA's is never anything but a mirror?

- if there is emergency for change, such should be made first non
  NonGNU ELPA, and followed by notice or issue to the original
  author. As each package is supposed to have name and maybe email
  address, that should be preferred way, rather than asking users to
  sign up on Github through non-free Javascript. Emergency can be if
  the packages breaks some other packages or some safety reasons, as
  many users would be eventually accessing the NonGNU ELPA.

- if there is no emergency, changes shall be collaborated with the
  author, if there is no author, then maintainer

- if there is no way to neither collaborate with the author, or
  maintainer, then comes the change in the NonGNU ELPA

Re: NonGNU ELPA

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

  > - if there is emergency for change, such should be made first non
  >   NonGNU ELPA, and followed by notice or issue to the original
  >   author.

  > - if there is no emergency, changes shall be collaborated with the
  >   author, if there is no author, then maintainer

If we put a package into NonGNU ELPA without knowing what sort of
cooperation we could have with its current maintainers, we would have
to go through options like these at the time of making a change.

What I have in mind is that we would determine, before putting a
package into NonGNU ELPA, where we stand vis-a-vis the maintainers.
We would set up the handling of the package according to that.  Thus,
on encountering a problem that suggests changing the package, we would
know in advance how to handle the issue.

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

NonGNU ELPA

[Stefan Monnier]

>> Stefan has a plan for bringing up NonGNU ELPA, but I think it
>> has been weeks since we discussed it and I have not heard that
>> he has moved forward on it.

I have a first cut up now.
The repository is at ssh://git.sv.gnu.org/srv/git/emacs/nongnu.git
and the archive is currently at https://elpa.gnu.org/nongnu/


        Stefan

Re: NonGNU ELPA

[Jean Louis]

* Stefan Monnier <monnier@iro.umontreal.ca> [2020-11-21 22:02]:
> >> Stefan has a plan for bringing up NonGNU ELPA, but I think it
> >> has been weeks since we discussed it and I have not heard that
> >> he has moved forward on it.
> 
> I have a first cut up now.
> The repository is at ssh://git.sv.gnu.org/srv/git/emacs/nongnu.git
> and the archive is currently at https://elpa.gnu.org/nongnu/

That is great! Big thank you.

How shall archive name be called in short? nongnu?

Re: NonGNU ELPA

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sat, 21 Nov 2020 14:02:38 -0500
> Cc: Richard Stallman <rms@gnu.org>, emacs-devel <emacs-devel@gnu.org>
> 
> >> Stefan has a plan for bringing up NonGNU ELPA, but I think it
> >> has been weeks since we discussed it and I have not heard that
> >> he has moved forward on it.
> 
> I have a first cut up now.
> The repository is at ssh://git.sv.gnu.org/srv/git/emacs/nongnu.git
> and the archive is currently at https://elpa.gnu.org/nongnu/

Great news, thanks!

Re: NonGNU ELPA

[Amin Bandali]

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

Eli Zaretskii writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Date: Sat, 21 Nov 2020 14:02:38 -0500
>> Cc: Richard Stallman <rms@gnu.org>, emacs-devel <emacs-devel@gnu.org>
>> 
>> >> Stefan has a plan for bringing up NonGNU ELPA, but I think it
>> >> has been weeks since we discussed it and I have not heard that
>> >> he has moved forward on it.
>> 
>> I have a first cut up now.
>> The repository is at ssh://git.sv.gnu.org/srv/git/emacs/nongnu.git
>> and the archive is currently at https://elpa.gnu.org/nongnu/
>
> Great news, thanks!
>

Great news indeed, many thanks!

Per discussion with rms, I will look into setting up elpa.nongnu.org for
use for NonGNU ELPA.  I believe that constitutes a better canonical
address for it.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 857 bytes --]

Re: NonGNU ELPA

[Jean Louis]

* Stefan Monnier <monnier@iro.umontreal.ca> [2020-11-21 22:02]:
> >> Stefan has a plan for bringing up NonGNU ELPA, but I think it
> >> has been weeks since we discussed it and I have not heard that
> >> he has moved forward on it.
> 
> I have a first cut up now.
> The repository is at ssh://git.sv.gnu.org/srv/git/emacs/nongnu.git
> and the archive is currently at https://elpa.gnu.org/nongnu/

I guess packages are unsigned and I hope they will become signed that
users can get feeling that packages do come from specific entity like
GNU project.

Following packages I propose for nonGNU ELPA:

- markdown-mode
  https://github.com/jrblevin/markdown-mode.git
  
- scad-mode
  https://raw.githubusercontent.com/openscad/openscad/8a905133a2f27e23db07bb424599a242c5d7176d/contrib/scad-mode.el

- scad-preview
  https://github.com/zk-phi/scad-preview.git

- jabber
  https://github.com/legoscia/emacs-jabber.git

- jabber-otr
  https://github.com/legoscia/emacs-jabber-otr.git

- helm
  https://github.com/emacs-helm/helm.git

- wordnut
  https://github.com/gromnitsky/wordnut.git

- sudoku
  https://github.com/zevlg/sudoku.el.git

- selectrum
  https://github.com/raxod502/selectrum.git

- mutt-mode
  https://gitlab.com/flexw/mutt-mode.git

- keycast
  https://github.com/tarsius/keycast.git

- kdeconnect
  https://github.com/carldotac/kdeconnect.el.git

- guide-key
  https://github.com/kai2nenobu/guide-key.git

- gemini-mode
  https://git.carcosa.net/jmcbray/gemini.el.git

- elpher
  git://thelambdalab.xyz/elpher.git

- 2048-game
  https://hg.sr.ht/~zck/game-2048

- sxiv
  https://gitlab.com/contrapunctus/sxiv.el

Re: NonGNU ELPA

[Stefan Monnier]

> I guess packages are unsigned

I would hope you'd take a quick look before assuming the worst,


        Stefan

Re: NonGNU ELPA

[Jean Louis]

* Stefan Monnier <monnier@iro.umontreal.ca> [2020-11-22 00:14]:
> > I guess packages are unsigned
> 
> I would hope you'd take a quick look before assuming the worst,

Maybe archive-contents is unsigned or something else. I have used
`package-check-signature' as it is default in my Emacs and I could not
get the archive, at least not first time.

Then let me blame my bad Internet connection.

Re: NonGNU ELPA

[Stefan Monnier]

>> > I guess packages are unsigned
>> I would hope you'd take a quick look before assuming the worst,
> Maybe archive-contents is unsigned or something else. I have used
> `package-check-signature' as it is default in my Emacs and I could not
> get the archive, at least not first time.
> Then let me blame my bad Internet connection.

Might be a problem on our side.  In any case, if you have problems with
that part, please consider it as a bug, because it's supposed to
work ;-)


        Stefan

Re: NonGNU ELPA

[Stefan Monnier]

> Following packages I propose for nonGNU ELPA:

I think more than suggestions for which packages to include, we're
looking for help in actually including them.


        Stefan

Re: NonGNU ELPA

[Jean Louis]

* Stefan Monnier <monnier@iro.umontreal.ca> [2020-12-04 06:53]:
> > Following packages I propose for nonGNU ELPA:
> 
> I think more than suggestions for which packages to include, we're
> looking for help in actually including them.

Give me assignment to do or tell me method to help.

Re: NonGNU ELPA

[Stefan Monnier]

>> > Following packages I propose for nonGNU ELPA:
>> I think more than suggestions for which packages to include, we're
>> looking for help in actually including them.
> Give me assignment to do or tell me method to help.

The README.org file in nongnu.git aims to do that.  It's still a work in
progress, but please read it.  This should either give you the info
needed for you to do the job, or should bring up new questions which I'd
be happy to answer.


        Stefan

Re: NonGNU ELPA

[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 hard part is making arrangements with the developers of each
package.  We are still trying to figure out exactly how to go about
this.  What we need now is for someone who understands the goal
clearly to give it a try.  Once we have one or two people who
can do this, they can write it down and/pr teach others.

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

Re: NonGNU ELPA

[Clément Pit-Claudel]

On 11/21/20 2:02 PM, Stefan Monnier wrote:
>>> Stefan has a plan for bringing up NonGNU ELPA, but I think it
>>> has been weeks since we discussed it and I have not heard that
>>> he has moved forward on it.
> 
> I have a first cut up now.
> The repository is at ssh://git.sv.gnu.org/srv/git/emacs/nongnu.git
> and the archive is currently at https://elpa.gnu.org/nongnu/

Great job!  Is the plan to put a copy of all the code in there, not just pointers to repositories?
Does that mean that authors will all have access to the git repo?  Will that access be limited to their individual externals/ branches?
Or will there be a script that pulls repositories into these individual branches?
And won't the repo become gigantic?

Clément.

Re: NonGNU ELPA

[Stefan Monnier]

> Or will there be a script that pulls repositories into these individual branches?

That!  And no, it's not written yet.
Note that this doesn't even have to run on elpa.gnu.org, you all can
participate in this effort ;-)

> And won't the repo become gigantic?

I don't expect it will become significantly larger than the actual ELPA
archive itself:

    % du -sh elpa/.git/ /var/www/html/packages/.
    886M    elpa/.git/
    918M    /var/www/html/packages/.
    % du -sh nongnu/.git/ /var/www/html/nongnu/.


-- Stefan

Re: NonGNU ELPA

[Jean Louis]

* Stefan Monnier <monnier@iro.umontreal.ca> [2020-11-22 00:19]:
> > Or will there be a script that pulls repositories into these individual branches?
> 
> That!  And no, it's not written yet.
> Note that this doesn't even have to run on elpa.gnu.org, you all can
> participate in this effort ;-)

Tell me how.

Re: NonGNU ELPA

[Clément Pit-Claudel]

On 11/21/20 4:18 PM, Stefan Monnier wrote:
> I don't expect it will become significantly larger than the actual ELPA
> archive itself:

I think the right metric would be the MELPA archive: I don't know how bit a complete checkout is of all MELPA packages.
The main problem would be cases in which an emacs mode exists as part of a larger repo (like llvm-mode, which is part of llvm — it was removed from MELPA because it took too long just to close the repo).

Re: NonGNU ELPA

[Jean Louis]

* Clément Pit-Claudel <cpitclaudel@gmail.com> [2020-11-22 01:22]:
> On 11/21/20 4:18 PM, Stefan Monnier wrote:
> > I don't expect it will become significantly larger than the actual ELPA
> > archive itself:
> 
> I think the right metric would be the MELPA archive: I don't know how bit a complete checkout is of all MELPA packages.

It is about 14 GB. If I change it slightly to --depth 1 it is about 10-11 GB.

Git is in my opinion not for releasing software, it is for
collaborative development. Releases of any software from git or other
version control systems should be packed and contain only what is
necessary for the user who receives such package. This is also because
authors or maintainers are deciding what is development version and
what is stable version. Git sources need not be stable and they do not
represent "release" and should not be regarded as release how MELPA is
accepting them.

The fact that many git repositories are online accessible does not
make them software releases. Author's opinion on what is release and
what is not shall be respected. But people did start going into
direction that git is automatically stable version which puts many
people and their data at stake.

Beside the git download size, when packages become packages after
building they are not so large, if I remember well just under 600 MB.

I am doing review of MELPA packages. There are many useless packages
and many unsafe and not polished and those repeating functions which
already exists. I would not include such.

There are those where author's name is not known as it is written only
as a nick. For me it would be legal problem as there is no truthful
authentic relation between the author who is not legally named "zack"
(example) and the receiver of software. Receiver would not know from
which entity or person did receive get the license, or both parties
would not have any option of defense or enforcement by the law.

> The main problem would be cases in which an emacs mode exists as
> part of a larger repo (like llvm-mode, which is part of lplvm — it
> was removed from MELPA because it took too long just to close the
> repo).

Isn't it not so that Emacs packages shall be either .el or .tar files?

Those packages that do not provide such releases and are useful can be
anyway packaged in non-GNU ELPA, why not? There is no need to
replicate git repositories, but rather actual packages regardless if
such are part of git repository or not.

Re: NonGNU ELPA

[Stefan Monnier]

> I think the right metric would be the MELPA archive: I don't know how bit
> a complete checkout is of all MELPA packages.

Hmm... wait, after "git gc" the figure is even more favorable:

    % du -sh elpa/.git/. /var/www/html/packages/.
    144M    elpa/.git/.
    918M    /var/www/html/packages/.
    %

IOW, the main problem with size is the ELPA archive itself rather than
the Git repository.

> The main problem would be cases in which an emacs mode exists as part of
> a larger repo (like llvm-mode, which is part of llvm — it was removed from
> MELPA because it took too long just to close the repo).

These need to be solved on a case-by-case basis, yes.


        Stefan

Re: NonGNU ELPA

[Stefan Kangas]

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

>> Or will there be a script that pulls repositories into these individual branches?
>
> That!  And no, it's not written yet.
> Note that this doesn't even have to run on elpa.gnu.org, you all can
> participate in this effort ;-)
>
>> And won't the repo become gigantic?
>
> I don't expect it will become significantly larger than the actual ELPA
> archive itself:

Is there any reason to suspect that this will become an issue?
AFAIK, Git is pretty good at handling large repositories.

Re: NonGNU ELPA

[Clément Pit-Claudel]

On 11/21/20 6:22 PM, Stefan Kangas wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
>>> Or will there be a script that pulls repositories into these individual branches?
>>
>> That!  And no, it's not written yet.
>> Note that this doesn't even have to run on elpa.gnu.org, you all can
>> participate in this effort ;-)
>>
>>> And won't the repo become gigantic?
>>
>> I don't expect it will become significantly larger than the actual ELPA
>> archive itself:
> 
> Is there any reason to suspect that this will become an issue?
> AFAIK, Git is pretty good at handling large repositories.

Cloning large repositories can be quite slow, that's it.  Assuming that no one needs to do this except the build machine, that should be fine, but if we want to push patches (as is sometimes done in ELPA) then it could become an issue?  
Even if it's not cloned often I worry about the time it takes to switch branches if very large external repositories get imported.

Re: NonGNU ELPA

[Stefan Monnier]

> Cloning large repositories can be quite slow, that's it.  Assuming that no
> one needs to do this except the build machine, that should be fine, but if
> we want to push patches (as is sometimes done in ELPA) then it could become
> an issue?

The plan is to try and refrain as much as possible from installing
patches directly into the nongnu.git mirrors.

IOW the complete copies held in nongnu.git are just meant as a kind of
"internal detail" to decouple the step of fetching updates from the step
of building packages.

> Even if it's not cloned often I worry about the time it takes to switch
> branches if very large external repositories get imported.

Every package gets into own branch, and gets its own worktree, so
switching branches should be very unusual there.
Also if having them all in a single repository ever turns out to be
a problem, we're definitely not stuck with this design.


        Stefan

Re: NonGNU ELPA

[Clément Pit-Claudel]

On 11/21/20 7:30 PM, Stefan Monnier wrote:
> Every package gets […] its own worktree

Oh, smart move. 👍

Re: NonGNU ELPA

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

  > Cloning large repositories can be quite slow, that's it.

Putting all the packages into one git repo is ok as an initial
implementation, but it isn't what we really want for NonGNU ELPA.  It
is meant to be a place where we will distribute/release packages side
by side -- not a hosting facility.  I think we will have to change
the structure.

Perhaps it should be a collection of git repos, one for each package,
as subdirectories of the main directory.  WHat else might be good?

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

Re: NonGNU ELPA

[Stefan Monnier]

> Putting all the packages into one git repo is ok as an initial
> implementation, but it isn't what we really want for NonGNU ELPA.

With all due respect, Richard, I believe you don't know Git enough to
make this judgment.


        Stefan

Re: NonGNU ELPA

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

  > > Putting all the packages into one git repo is ok as an initial
  > > implementation, but it isn't what we really want for NonGNU ELPA.

  > With all due respect, Richard, I believe you don't know Git enough to
  > make this judgment.

You are probably right -- but I have to judge how this compares with
the plan, and I can only do it based on the knowledge available to me.
Your description didn't add much to my limited background.

Would you please explain to me how your implementation works, so I can
see why I was wrong to worry about this, and other important things?

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

Re: NonGNU ELPA

[Stefan Kangas]

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

>>> Stefan has a plan for bringing up NonGNU ELPA, but I think it
>>> has been weeks since we discussed it and I have not heard that
>>> he has moved forward on it.
>
> I have a first cut up now.
> The repository is at ssh://git.sv.gnu.org/srv/git/emacs/nongnu.git
> and the archive is currently at https://elpa.gnu.org/nongnu/

Excellent news!  Thank you for this work.

Re: NonGNU ELPA

[Stefan Kangas]

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

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

> I have a first cut up now.
> The repository is at ssh://git.sv.gnu.org/srv/git/emacs/nongnu.git
> and the archive is currently at https://elpa.gnu.org/nongnu/

To build it locally, are the instructions in the README from GNU ELPA
the ones to follow?

How easy is it to add a package?  Would pushing the attached patch do
the job?  Is it useful to start adding packages at this stage?

[-- Attachment #2: 0001-externals-list-New-package-magit.patch --]
[-- Type: text/x-diff, Size: 803 bytes --]

From 21294a45866d186259088a72780ab5718fadb50d Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefan@marxist.se>
Date: Sun, 22 Nov 2020 00:27:10 +0100
Subject: [PATCH] * externals-list: New package `magit`

---
 externals-list | 1 +
 1 file changed, 1 insertion(+)

diff --git a/externals-list b/externals-list
index ba4edbf6..da180492 100644
--- a/externals-list
+++ b/externals-list
@@ -32,6 +32,7 @@
   ;; The version 4.7.1 from Melpa-stable seems to correspond to
   ;; revision a9134009.
   :version-map ((nil "4.7.1" "a9134009bd037a39cbda21806867d0534d340bca")))
+ ("magit"		:external "https://github.com/magit/magit")
  ("sly"			:external "https://github.com/joaotavora/sly"
   :version-map (("1.0.0-beta-3" "1.0.0beta3")))
  ("tuareg"		:external "https://github.com/ocaml/tuareg.git")
-- 
2.29.2

Re: NonGNU ELPA

[Stefan Monnier]

> To build it locally, are the instructions in the README from GNU ELPA
> the ones to follow?

Yes and no.

To build the packages, it's much easier:

    git clone .../nongnu.git
    cd nongnu
    make build/sly

or "make build-all"

And the result is put into `archive` (as well as `archive-devel` which
is what you see in https://elpa.gnu.org/nongnu-devel/ and corresponds
to the non-stable Melpa more or less).

To "compile the packages in place", you can do "make" and it should work
more or less like for elpa.git, but it probably has some rough edges
(e.g. a subsequent "make build/sly" might burp because it expects
a clean worktree and it might mess with the .gitignore file or
something.  This part of the code needs to be adapted to the new
context).

If you feel like taking a shot at the README, that would be welcome ;-)

> How easy is it to add a package?  Would pushing the attached patch do
> the job?

It might, but you'll also need to push the code of Magit to the
`externals/magit` branch, like in elpa.git.

IIUC Magit has various Package-Requires, so you'll have to add those
first since we don't want nongnu.git package to require packages only
found in Melpa.

> Is it useful to start adding packages at this stage?

Yes.


        Stefan

Re: NonGNU ELPA

[Stefan Kangas]

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

> It might, but you'll also need to push the code of Magit to the
> `externals/magit` branch, like in elpa.git.

Will subsequent updates happen automatically, or does it require
manually pushing to that branch like in GNU ELPA?

Re: NonGNU ELPA

[Stefan Monnier]

> Will subsequent updates happen automatically, or does it require
> manually pushing to that branch like in GNU ELPA?

The code to fetch+push is still vaporware, so you have to do it by hand,
like for GNU ELPA.


        Stefan

Re: NonGNU ELPA

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

  > How easy is it to add a package?  Would pushing the attached patch do
  > the job?  Is it useful to start adding packages at this stage?

In general we are not ready to fill it with packages.

First of all, this is a first stab at setting up NonGNU ELPA.  Does it
do the right thing?  Does it need changes?  The message about it was
very terse, and I am not sure what Stefan has implemented.

Aside from the technical structure, we have to develop procedures.
Before we put a package into NonGNU ELPA, we have to look it over and
make sure it follows the rules.  (I posted them here months ago.)
Also make sure there is nothing problematical in it.

Then we have to determine what relationship to have with its
development.  There are three possibilities.

1. Make an arrangement with its developers, then entrust it to them by
automatically copying their new releases.

2. Automatically copy in new releases, but check them to make sure
the code does not become problematical.

3. Manually to check and install new versions occasionally,
carrying forward our small changes as if necessary.

We will need to work out the details of this by doing it.
What we need to do now is add packages carefully, one by one,
paying attention to the arrangements we make for each one.


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

Re: NonGNU ELPA

[Stefan Kangas]

Richard Stallman <rms@gnu.org> writes:

> Before we put a package into NonGNU ELPA, we have to look it over and
> make sure it follows the rules.  (I posted them here months ago.)
> Also make sure there is nothing problematical in it.
>
> Then we have to determine what relationship to have with its
> development.  There are three possibilities.
>
> 1. Make an arrangement with its developers, then entrust it to them by
> automatically copying their new releases.
>
> 2. Automatically copy in new releases, but check them to make sure
> the code does not become problematical.
>
> 3. Manually to check and install new versions occasionally,
> carrying forward our small changes as if necessary.
>
> We will need to work out the details of this by doing it.
> What we need to do now is add packages carefully, one by one,
> paying attention to the arrangements we make for each one.

This implies that we should first contact the package maintainer telling
them that we are interested in adding it to GNU ELPA.  I think that
could be useful, as it's also an opportunity for us to inform the
package maintainer about our plans, to build a relationship and to avoid
surprising anyone.

I have three questions:

Would it be useful to prepare a template for such a communication?

Could we prepare a canonical URL for the GNU ELPA package
requirements/rules outlined in a previous email by Richard?  I assume it
would be placed under https://elpa.nongnu.org/requirements.htm or
something similar, once Amin can get that hostname working.

Should we add a special file to nongnu.git for recording the kind of
arrangement we decide on?  I imagine that our ideal case would be number
one above.  Perhaps we would only need to note anything down when we
have a different arrangement from the first case.

Re: NonGNU ELPA

[Jean Louis]

* Stefan Kangas <stefankangas@gmail.com> [2020-11-24 23:06]:
> I have three questions:
> 
> Would it be useful to prepare a template for such a communication?
> 
> Could we prepare a canonical URL for the GNU ELPA package
> requirements/rules outlined in a previous email by Richard?  I assume it
> would be placed under https://elpa.nongnu.org/requirements.htm or
> something similar, once Amin can get that hostname working.
> 
> Should we add a special file to nongnu.git for recording the kind of
> arrangement we decide on?  I imagine that our ideal case would be number
> one above.  Perhaps we would only need to note anything down when we
> have a different arrangement from the first case.

Some thoughts:

You should take notes by date on the relation with the developers as
that helps greatly other developers to understand what it is. Any
communication with developer as it is public should be quickly
accessible from such notes. If there is specific decision or anything
in the mailing list to be noted, you may insert URL to the message in
such notes.

Note could contain:

- dates of notes
- names and contact information
- sources URLs and changes of such
- references to previous decisive communication objects

Re: NonGNU ELPA

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

  > > We will need to work out the details of this by doing it.
  > > What we need to do now is add packages carefully, one by one,
  > > paying attention to the arrangements we make for each one.

  > This implies that we should first contact the package maintainer telling
  > them that we are interested in adding it to GNU ELPA.  I think that
  > could be useful, as it's also an opportunity for us to inform the
  > package maintainer about our plans, to build a relationship and to avoid
  > surprising anyone.

Yes indeed.

  > I have three questions:

  > Would it be useful to prepare a template for such a communication?

Yes, definitely.

Would you like to write a draft of this, and show it to me and
the other Emacs maintainers?  Privately at first.

  > Could we prepare a canonical URL for the GNU ELPA package
  > requirements/rules outlined in a previous email by Richard?  I assume it
  > would be placed under https://elpa.nongnu.org/requirements.htm or
  > something similar, once Amin can get that hostname working.

Yes, we should do that.  It should state the full rules, which
I've posted here, adding some details from my previous message.
I'll do make that and send it to you.

  > Should we add a special file to nongnu.git for recording the kind of
  > arrangement we decide on?

Yes.  One question is where to put that information:
in one single file with an item for each package, or in a
file for each package in that package's information?

(What is the structure of the archive?
Does each package have a page?
Does each package have a subdirectory?
How are the files presented for download?)

                               I imagine that our ideal case would be number
  > one above.

Yes.

                Perhaps we would only need to note anything down when we
  > have a different arrangement from the first case.

No, that would risk misunderstandings in the harmful direction:
that we would believe the package is being taken care of by someone
else who has not in fact accepted that responsibility.

To avoid this. we should always indicate explicitly who has taken
responsibility for the updating of each package in NonGNU ELPA.



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

Re: NonGNU ELPA

[Stefan Monnier]

>   > Could we prepare a canonical URL for the GNU ELPA package
>   > requirements/rules outlined in a previous email by Richard?  I assume it
>   > would be placed under https://elpa.nongnu.org/requirements.htm or
>   > something similar, once Amin can get that hostname working.
>
> Yes, we should do that.  It should state the full rules, which
> I've posted here, adding some details from my previous message.
> I'll do make that and send it to you.

FWIW, I've put that in the README.org of nongnu.git
(http://git.savannah.gnu.org/cgit/emacs/nongnu.git/tree/README.org) in
the "Guidance for accepting packages" 


        Stefan

Re: NonGNU ELPA

[Stefan Kangas]

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

> > Yes, we should do that.  It should state the full rules, which
> > I've posted here, adding some details from my previous message.
> > I'll do make that and send it to you.
>
> FWIW, I've put that in the README.org of nongnu.git
> (http://git.savannah.gnu.org/cgit/emacs/nongnu.git/tree/README.org) in
> the "Guidance for accepting packages"

Excellent.  Why not export README.org as a HTML file and distribute it
as such on nongnu.elpa.org?  Org-mode already has excellent HTML
exporting capabilities that we could use, and it is trivial to adapt
it to use the existing stylesheet.  We could perhaps do the same with
the link to the README on elpa.gnu.org (where we currently just link
the raw text file on Savannah's gitweb).

I would ideally like to see a menu added to both NonGNU ELPA and GNU
ELPA web pages.  For example, on elpa.gnu.org you can only find
"Contribute" from the very first entry page, which is fine, but to my
mind not ideal.  It should better be shown on every page.  A menu
should make it easier to find information on what NonGNU/GNU ELPA is,
and how to install and submit packages.

I think we could have these menu entries: "Packages", "How to install"
and "Contributing", and perhaps even a brief FAQ.  I could volunteer
to write the text for these pages, but I often find CSS very
frustrating to work with so it takes me a lot of mental willpower to
do even simple things like a menu.  Perhaps someone on this list is
more CSS-capable than me and would be willing to help here.  (I do
have a half-baked attempt lying around that I have lacked the stamina
to complete.)

Re: NonGNU ELPA

[Stefan Monnier]

> Excellent.  Why not export README.org as a HTML file and distribute it
> as such on nongnu.elpa.org?

To most of those questions, the answer is all the same: because noone
did it.  Help very welcome (and if there's any question about how to
get it done, I'd be happy to help as well).


        Stefan

Re: NonGNU ELPA

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 27 Nov 2020 08:56:06 -0500
> Cc: Amin Bandali <bandali@gnu.org>, Richard Stallman <rms@gnu.org>,
>  Emacs developers <emacs-devel@gnu.org>
> 
> > Excellent.  Why not export README.org as a HTML file and distribute it
> > as such on nongnu.elpa.org?
> 
> To most of those questions, the answer is all the same: because noone
> did it.

Indeed, as everything else in Emacs (and in Free Software in general).

> Help very welcome (and if there's any question about how to get it
> done, I'd be happy to help as well).

Indeed, I'd encourage people to offer help in getting this done
instead of asking why wasn't it.  Thanks in advance!

Re: NonGNU ELPA

[Jean Louis]

* Stefan Kangas <stefankangas@gmail.com> [2020-11-27 12:15]:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> > > Yes, we should do that.  It should state the full rules, which
> > > I've posted here, adding some details from my previous message.
> > > I'll do make that and send it to you.
> >
> > FWIW, I've put that in the README.org of nongnu.git
> > (http://git.savannah.gnu.org/cgit/emacs/nongnu.git/tree/README.org) in
> > the "Guidance for accepting packages"
> 
> Excellent.  Why not export README.org as a HTML file and distribute it
> as such on nongnu.elpa.org?

Not directly related, the SSL certificate is for now not valid on
elpa.nongnu.org

Re: NonGNU ELPA

[Jean Louis]

* Stefan Monnier <monnier@iro.umontreal.ca> [2020-11-26 17:20]:
> > Yes, we should do that.  It should state the full rules, which
> > I've posted here, adding some details from my previous message.
> > I'll do make that and send it to you.
> 
> FWIW, I've put that in the README.org of nongnu.git
> (http://git.savannah.gnu.org/cgit/emacs/nongnu.git/tree/README.org) in
> the "Guidance for accepting packages" 

Thank you Stefan.

I may have just few thoughts on README.org and I know it is in
progress to be polished.

- head is missing to explain in brief what is nonGNU ELPA

- Regarding heading "The Emacs maintainers will decide what packages
  to put in NonGNU ELPA." as this heading comes so early in "Guidance
  for accepting packages", I would say that the tone of that heading
  gives on me as non native English speaker somewhat negative or
  little bit unwelcoming impression. Maybe it can be said that
  everybody is welcome to apply to include packages in nonGNU ELPA and
  that Emacs maintainers will have final decision based on various
  GNU free software policies. Something like that should or could be
  the first what users read.

- The Org headings are made so that it is not really heading rather
  begin of a sentence. Heading should be summary of a paragraph
  below. I know this is all in progress.

- I feel this sentence as defensive and reiteration what was
  previously said: "** If an ELisp package follows the rules below, we
  can add it to NonGNU ELPA if we want to." -- Instead one could
  formulate it in some positive manner: "Please review the rules below
  and align your package to conform to it to help maintainers make a
  decision" -- something like that, but maybe better formulated.

- "We may also change the code in NonGNU ELPA for other reasons,
  technical or not.  After all, it is free software." -- that is all
  clear and good, I just feel it is defensive for no apparent
  reason. In my opinion it requires some adaptations similar to above.

- "let's discuss it" should have clear pointers which communication
  lines to use, for example there could be hyperlins to the mailing
  list, or how to subscribe to mailing list, or some other
  communication lines. Among thousands of authors it is so that only
  subset of them is participating in GNU mailing lists. They need not
  know how to contact. Also website should give pointers on how to
  contact Emacs maintainers.

- README.org for nonGNU ELPA once polished could be included in etc/
  in distribution

- "FSF conventions" should be maybe hyperlinked to FSF and conventions
  as this way we give some references for further learning as maybe
  people wish to apply with their packages directly to GNU ELPA as
  well and may wish to contribute to Emacs directly. References and
  pointers to that type of contribution should also be included.

- In general I would myself hyperlink many terms such as GNU operating
  system, GNU/Linux to reference on GNU with differences in terms of
  Linux and GNU

- I would exclude the Savannah rule about advertisement as if it is
  general rule than those who advertise may be later warned why, as if
  it is final decision of Emacs maintainers then maintainers will
  handle those incidents. This paragraph is IMHO not necessary as may
  drive people away. It is easy to warn somebody. Advertising could be
  construed as simple placing of a hyperlink. Or telling "Copyright
  Free Software or ABC Foundation". Or otherwise one should clearly
  define what advertisement means.

  When one say "you may not advertise anything commercial" does it
  mean that some commercially sold free software cannot be placed in
  the repository?

  Then there are exeption cited about fan items that one may sell
  directly to user which is somehow contradictory.

  In general that section should be maybe defined better or removed
  and defined in general Savannah rules. As README.org could be
  eventually distributed or mirrored, it can get wide
  distribution. That is why is better to now revise whatever
  maintainers wish to revise.

- "Adding a package" is there, and fine, but nothing says about how
  authors or other people may propose packages to be included. That is
  missing as first step for people to contribute.

- in general it should be more welcoming for contributors to feel more
  free to apply and contribute and to have references how to apply and
  how to contribute. While this is explained partially, it may need
  more description and clarifications.

- There shall be more references to GNU ELPA, to Emacs Lisp manual and
  section Packaging and GNU website.

Thank you for considerations,
Jean

Re: NonGNU ELPA

[Stefan Monnier]

> I may have just few thoughts on README.org and I know it is in
> progress to be polished.

A patch would be greatly appreciated, yes,


        Stefan

Re: NonGNU ELPA

[Jean Louis]

* Stefan Monnier <monnier@iro.umontreal.ca> [2020-11-27 18:22]:
> > I may have just few thoughts on README.org and I know it is in
> > progress to be polished.
> 
> A patch would be greatly appreciated, yes,

I would gladly, I am not sure if it is appropriate at this moment
yet as I do not know about agreements between people on how it should
all look like.

Please look this README:
http://git.savannah.gnu.org/cgit/emacs/elpa.git/plain/README

In my opinion this README shall be cloned to nonGNU ELPA and then
adapted with points you have there.

Re: NonGNU ELPA

[Stefan Kangas]

Jean Louis <bugs@gnu.support> writes:

> > > I may have just few thoughts on README.org and I know it is in
> > > progress to be polished.
> >
> > A patch would be greatly appreciated, yes,
>
> I would gladly, I am not sure if it is appropriate at this moment
> yet as I do not know about agreements between people on how it should
> all look like.

A patch is appropriate at this time, yes.  It will help us make the
necessary changes and find any points of contention as well.

FWIW, I think all your proposals sound basically good and I don't
expect they should be very controversial.  Perhaps we would need to
adapt this or that detail, but that is done as a matter of course with
any patch.

Re: NonGNU ELPA

[Stefan Kangas]

Richard Stallman <rms@gnu.org> writes:

>   > Would it be useful to prepare a template for such a communication?
>
> Yes, definitely.
>
> Would you like to write a draft of this, and show it to me and
> the other Emacs maintainers?  Privately at first.

Yes, I can do that.  I will send it privately when I have prepared it.

>   > Could we prepare a canonical URL for the GNU ELPA package
>   > requirements/rules outlined in a previous email by Richard?  I assume it
>   > would be placed under https://elpa.nongnu.org/requirements.htm or
>   > something similar, once Amin can get that hostname working.
>
> Yes, we should do that.  It should state the full rules, which
> I've posted here, adding some details from my previous message.
> I'll do make that and send it to you.

Thank you.

>   > Should we add a special file to nongnu.git for recording the kind of
>   > arrangement we decide on?
>
> Yes.  One question is where to put that information:
> in one single file with an item for each package, or in a
> file for each package in that package's information?

I have no strong opinion either way.  Perhaps centralizing it in a
single file is easier to maintain.

> Does each package have a page?

Yes, see for example: https://elpa.gnu.org/nongnu/caml.html

> Does each package have a subdirectory?

AFAIU, the answer is no.  They instead each have their own git branch.

> How are the files presented for download?)

They are either .el or .tar files available using the standard M-x
package-list in Emacs, or the individual package page with a web
browser.

>                 Perhaps we would only need to note anything down when we
>   > have a different arrangement from the first case.
>
> No, that would risk misunderstandings in the harmful direction:
> that we would believe the package is being taken care of by someone
> else who has not in fact accepted that responsibility.
>
> To avoid this. we should always indicate explicitly who has taken
> responsibility for the updating of each package in NonGNU ELPA.

OK, that sounds reasonable.

Re: NonGNU ELPA

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

  > > Yes, we should do that.  It should state the full rules, which
  > > I've posted here, adding some details from my previous message.
  > > I'll do make that and send it to you.

  > Thank you.

I've cleaned up the points about what we should do to add a package to
NonGNU ELPA.  Does anyone suggest any further changes?


Before we put a package into NonGNU ELPA, we have to look it over and
make sure it follows the rules.  We also have to check that there is
technically or ethically problematical in it.  If users like the
package and have not complained about it, we can take that as meaning
it is good to use.  But we should also check its namespace usage.

Then we have to determine what relationship to have with its
development.  There are three possibilities.

1. Make an arrangement with its developers, then entrust it to them by
automatically copying their new releases.

2. Automatically copy in new releases, but check them to make sure the
code does not become problematical.  If it does, we could accept the
new version and discuss the matter with the developers, make some changes,
or back up the version in NonGNU ELPA to a previous release.

3. Manually check and install new versions when convenient, carrying
forward our own changes (small, we hope) and occasionally making
more changes.

We will need to work out the details of this by doing it.
What we need to do now is add packages carefully, one by one,
paying attention to the arrangements we make for each one.
-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: NonGNU ELPA

[Stefan Kangas]

Richard Stallman <rms@gnu.org> writes:

> I've cleaned up the points about what we should do to add a package to
> NonGNU ELPA.  Does anyone suggest any further changes?

One small comment:

> Before we put a package into NonGNU ELPA, we have to look it over and
> make sure it follows the rules.  We also have to check that there is
> technically or ethically problematical in it.  If users like the
  ^ "nothing" seems to be missing here

> package and have not complained about it, we can take that as meaning
> it is good to use.  But we should also check its namespace usage.

Otherwise, LGTM.

Re: NonGNU ELPA

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

  > > Before we put a package into NonGNU ELPA, we have to look it over and
  > > make sure it follows the rules.  We also have to check that there is
  > > technically or ethically problematical in it.  If users like the
  >   ^ "nothing" seems to be missing here

You're right.

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

Re: NonGNU ELPA

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

  > > Does each package have a subdirectory?

  > AFAIU, the answer is no.  They instead each have their own git branch.

Could you explain to me what that means?  I know about branches in git.
Normally a branch will contain a modified version of the program
that is in master.  That is not what we want here.

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

Re: NonGNU ELPA

[Andrea Corallo via Emacs development discussions.]

Richard Stallman <rms@gnu.org> writes:

[...]

> Could you explain to me what that means?  I know about branches in git.
> Normally a branch will contain a modified version of the program
> that is in master.

This is how is often used, but a git branch does not have to necessarily
share the root commit with master (or any other branch).  I believe this
kind of branch is called 'orphan'.

  Andrea

Re: NonGNU ELPA

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

  > This is how is often used, but a git branch does not have to necessarily
  > share the root commit with master (or any other branch).  I believe this
  > kind of branch is called 'orphan'.

Thanks.

I think this structure be explained in the README file
or some other prominent place.  Is that the case now?

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

Re: NonGNU ELPA

[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 repository is at ssh://git.sv.gnu.org/srv/git/emacs/nongnu.git
  > and the archive is currently at https://elpa.gnu.org/nongnu/

Could you explain how this works?
What role does the repo play,
and what role does the archive play?

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

Re: NonGNU ELPA

[Zhu Zihao]

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


Thanks for your work.

Would you mind add a rsync service? This can help mirror providers like
https://elpa.emacs-china.org/ to mirror the NonGNU ELPA more easily.

Stefan Monnier writes:

>>> Stefan has a plan for bringing up NonGNU ELPA, but I think it
>>> has been weeks since we discussed it and I have not heard that
>>> he has moved forward on it.
>
> I have a first cut up now.
> The repository is at ssh://git.sv.gnu.org/srv/git/emacs/nongnu.git
> and the archive is currently at https://elpa.gnu.org/nongnu/
>
>
>         Stefan


-- 
Retrieve my PGP public key: https://meta.sr.ht/~citreu.pgp

Zihao

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 515 bytes --]

Re: NonGNU ELPA

[Stefan Monnier]

> Would you mind add a rsync service?

Oh, yes, I forgot to update the rsync service.
It should be fixed now.  Beside `elpa`, there's now `nongnu` and `nongnu-devel`.
Thanks for the reminder,


        Stefan


> This can help mirror providers like
> https://elpa.emacs-china.org/ to mirror the NonGNU ELPA more easily.
>
> Stefan Monnier writes:
>
>>>> Stefan has a plan for bringing up NonGNU ELPA, but I think it
>>>> has been weeks since we discussed it and I have not heard that
>>>> he has moved forward on it.
>>
>> I have a first cut up now.
>> The repository is at ssh://git.sv.gnu.org/srv/git/emacs/nongnu.git
>> and the archive is currently at https://elpa.gnu.org/nongnu/
>>
>>
>>         Stefan

Re: NonGNU ELPA

[Daniel Martín]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> I have a first cut up now.

Thanks for working on this!

> The repository is at ssh://git.sv.gnu.org/srv/git/emacs/nongnu.git

This SSH address does not work here because it requires authentication.
Does it need a Savannah account, by chance?  I simply wanted to clone
the repository anonymously, so I "discovered"
https://git.savannah.gnu.org/cgit/emacs/nongnu.git and issued a

git clone git://git.savannah.gnu.org/emacs/nongnu.git

to make my computer clone the repo.  Sorry if this is a well-known
workflow that is the same as in GNU ELPA, I'm not familiar with Emacs
package repositories.

> and the archive is currently at https://elpa.gnu.org/nongnu/
>

Is there a plan to include this package archive by default in a future
version of Emacs?  That is, something like

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

If so, then I have a potential feature once we have a few language modes
in NonGNU ELPA (I see there's already Markdown and OCaml): When you open
a file with ".md" extension for the first time, Emacs will ask whether
you want to install markdown-mode from NonGNU ELPA, instead of opening
the Markdown file in fundamental-mode.  Does this make sense?  To make
it really useful, as the cadence of Emacs releases and NonGNU ELPA
changes will surely be different, we'd somehow need to implement it in a
way that does not couple the Emacs source code to the language mode
packages available in NonGNU ELPA, if that's possible.

Re: NonGNU ELPA

[Jean Louis]

* Daniel Martín <mardani29@yahoo.es> [2020-12-05 14:46]:
> If so, then I have a potential feature once we have a few language modes
> in NonGNU ELPA (I see there's already Markdown and OCaml): When you open
> a file with ".md" extension for the first time, Emacs will ask whether
> you want to install markdown-mode from NonGNU ELPA, instead of opening
> the Markdown file in fundamental-mode.  Does this make sense?  To make
> it really useful, as the cadence of Emacs releases and NonGNU ELPA
> changes will surely be different, we'd somehow need to implement it in a
> way that does not couple the Emacs source code to the language mode
> packages available in NonGNU ELPA, if that's possible.

That may be useful as option to be decided by the subset of users who
need it.

It better not be by default to nag those who may not need it.

Have been editing markdown since 2004 and just before 1-2 years have
discovered markdown-mode. The only thing I need in that mode is
preview which I can do myself by assigning a key to
function. Markdown's goal was always simplicity and being able to edit
with any editor. That is just to tell you of my user experience and
habit.

Re: NonGNU ELPA

[Stefan Monnier]

>> The repository is at ssh://git.sv.gnu.org/srv/git/emacs/nongnu.git
> This SSH address does not work here because it requires authentication.

Indeed, that's the URL to use if you want write access.
For read-only access you have to use:

> git clone git://git.savannah.gnu.org/emacs/nongnu.git

;-)

>> and the archive is currently at https://elpa.gnu.org/nongnu/
> Is there a plan to include this package archive by default in a future
> version of Emacs?

Yes (tho with a slightly different URL with `elpa.nongnu.org`).

> If so, then I have a potential feature once we have a few language modes
> in NonGNU ELPA (I see there's already Markdown and OCaml): When you open
> a file with ".md" extension for the first time, Emacs will ask whether
> you want to install markdown-mode from NonGNU ELPA, instead of opening
> the Markdown file in fundamental-mode.  Does this make sense?

We already have that for those packages in GNU ELPA if you install the
`gnu-elpa` package (which I still hope we'll be able to bundle within
the tarball of Emacs-28).
We could easily extend it to the NonGNU archive, indeed.


        Stefan

Re: NonGNU ELPA

[Daniel Martín]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> We already have that for those packages in GNU ELPA if you install the
> `gnu-elpa` package (which I still hope we'll be able to bundle within
> the tarball of Emacs-28).
> We could easily extend it to the NonGNU archive, indeed.
>

Ah, I didn't know about the gnu-elpa package.  I haven't tested it yet,
but it looks like it already implements the feature I suggested.  Good
thing it is considered for inclusion with Emacs 28.

Re: NonGNU ELPA

[Stefan Monnier]

>> We already have that for those packages in GNU ELPA if you install the
>> `gnu-elpa` package (which I still hope we'll be able to bundle within
>> the tarball of Emacs-28).
>> We could easily extend it to the NonGNU archive, indeed.
> Ah, I didn't know about the gnu-elpa package.  I haven't tested it yet,
> but it looks like it already implements the feature I suggested.

It's quite young and would benefit from feedback from users, BTW.

> Good thing it is considered for inclusion with Emacs 28.

Not sure it's considered yet, to be honest.  I'd like it, but it's not
my decision.


        Stefan