NonGNU ELPA and release frequency

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

[Stefan Kangas]

Antoine Kalmbach <ane@iki.fi> writes:

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

AFAIK, the details you are asking about are not yet decided.

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

I strongly agree that NonGNU ELPA is "necessary and requires attention",
but I don't understand which discussions you are referring to above.
Could you perhaps link some of these discussions, or give a brief
summary?

Re: NonGNU ELPA and release frequency

[Antoine Kalmbach]

Stefan Kangas <stefankangas@gmail.com> writes:

> I strongly agree that NonGNU ELPA is "necessary and requires attention",
> but I don't understand which discussions you are referring to above.
> Could you perhaps link some of these discussions, or give a brief
> summary?

Well, it gets mentioned here from time to time, most recently in the
Emacs survey thread.  Elsewhere, on Reddit[1] I observed meta-discussion
about this aforementioned survey thread on emacs-devel, also on
lobste.rs[2] in comments to a post about the survey itself.

I think a good summary is--correct me if I'm wrong!--that

   * People want to contribute packages to a package repository that is
     available in Emacs by default
   * People do not necessary want to go through the trouble of assigning
     copyright to the FSF to get their packages to GNU ELPA
   * People want the process of contributing packages to this repository
     to be lightweight (or at least more lightweight than of ELPA)

I think all of these are clear goals of NonGNU ELPA.  This much is
obvious from the NonGNU ELPA announcement email from August.

The important thing is, is that at least from what I've seen based on
these discussions, the goals of NonGNU ELPA really match the needs of
Emacs users, and the recent discussions regarding MELPA here and
elsewhere only corroborates this.  

What is striking is that people seem to acknowledge MELPA was never
nothing but a compromise to begin with. Once Emacs can offer an official
alternative that is both practical and yet respectful of user freedoms
the compromise is no longer necessary.  At least, that is only my
impression, your mileage may.

[1] https://www.reddit.com/r/emacs/comments/je3eht/emacs_user_survey_2020_is_open/
[2] https://lobste.rs/s/7ynrre/state_emacs_survey

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

Would you like to help implement 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 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

[Antoine Kalmbach]

Richard Stallman <rms@gnu.org> writes:

> Would you like to help implement NonGNU ELPA?

Sure.

-- 
Antoine Kalmbach

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

[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

[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 and release frequency

[Stefan Monnier]

FWIW, I was hoping to set it up this week, but obviously, time passed
faster than planned.

My plan was to take the GNU ELPA infrastructure, duplicate it to the
(currently empty) emacs/nongnu.git repository, tweak it mostly by
removing the parts that aren't applicable (i.e. only support "external"
package), then add a few packages.

It would run on elpa.gnu.org and be served under elpa.gnu.org/nongnu

After that, I would have started to work on scripts to pull from remote
Git repositories and push to the corresponding nongnu.git branch, and
then improving the ELPA scripts so that single packages can be rebuilt
instead of always rebuilding them all.


        Stefan

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

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

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

Did you mean NonGNU ELPA here?  I think so, because we GNU ELPA is a
different topic and we don't plan to change how we handle it.

NonGNU ELPA will be our system for redistributing whatever published
Lisp packages we want to redistribute.  If a package meets our
criteria, we will put it in. modifying it if we find that necessary.
GPL3+ compatible license will be the first criterion but not the only
criterion.

I don't think we will belooking for packages to be "contributed to
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 and release frequency

[Dmitry Gutov]

On 25.10.2020 05:48, Richard Stallman wrote:
> 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).

So... no packages hosted on Github?

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

[Stefan Monnier]

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

The way I plan to make NonGNU ELPA (if someone beats me to it) is to
make it work *internally* like GNU ELPA: each package would have
a corresponding branch in the nongnu.git repository.

The difference is that these branches would just be mirrors from the
corresponding upstream branch which can be kept "anywhere else", and
there'd be some automation to *pull* automatically from those
repositories (where in GNU ELPA we require maintainers to *push* to the
central repository) so the maintainers don't need write access to the
whole repository (they technically wouldn't even need to know that their
package is on nongnu.git).


        Stefan

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

[Antoine Kalmbach]

Ivan Yonchovski <yyoncho@gmail.com> 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?

I suppose maintenance here means that the work required by the NonGNU
ELPA maintainers means running nonfree JS. As far as I know, the only
nonfree JS for Github is needed during the signup process, but pulling
from upstream repositories hosted on Github requires no JS, and even
browsing Github works with LibreJS, the signup process is the
problematic part.

For reference, `grep -c github` on
http://elpa.gnu.org/packages/archive-contents returns 82, so a
significant amount of external packages in GNU ELPA list Github as their
:url. 

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

  > FWIW, I was hoping to set it up this week, but obviously, time passed
  > faster than planned.

  > My plan was to take the GNU ELPA infrastructure, duplicate it to the
  > (currently empty) emacs/nongnu.git repository, tweak it mostly by
  > removing the parts that aren't applicable (i.e. only support "external"
  > package), then add a few packages.

  > It would run on elpa.gnu.org and be served under elpa.gnu.org/nongnu

  > After that, I would have started to work on scripts to pull from remote
  > Git repositories and push to the corresponding nongnu.git branch, and
  > then improving the ELPA scripts so that single packages can be rebuilt
  > instead of always rebuilding them all.

I think that road will get to the right destination.

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

[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 and release frequency

[Philip K.]

Antoine Kalmbach <ane@iki.fi> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> Would you like to help implement NonGNU ELPA?
>
> Sure.

I'd love to help to, just don't know what help is required.

-- 
	Philip K.

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 and release frequency

[Dmitry Gutov]

On 26.10.2020 06:10, Richard Stallman wrote:

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

All right, then.

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

Would we have packages where the maintainers don't cooperate, though?

At best, such a package should be a fork, but then it could also be 
renamed, and then hosted on Savannah, or wherever.

In the common case, the package maintainer should in contact.

The GNU ELPA experience shows that unilateral changes coming from "us" 
and not from maintainers are rare. They should be rarer still in the 
case of Non-GNU ELPA.

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

  > I'd love to help to, just don't know what help is required.

Please ask Stefan Monnier to suggest ways you can help him make
progress.

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

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

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

  > Would we have packages where the maintainers don't cooperate, though?

We will not shy away from including such packages if they are useful
to include.

  > At best, such a package should be a fork, but then it could also be 
  > renamed, and then hosted on Savannah, or wherever.

Why would we want to include a package even though its maintainer will
not cooperate?  Probably because users want to use it the way it is.

So we would not want to change what it does for the user, nor the
package name users are accustomed to.


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

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