Adding advisory notification for non-ELPA package.el downloads

Adding advisory notification for non-ELPA package.el downloads

[John Wiegley]

Richard recently suggested the idea of adding a notification message -- to
remain completely unobtrusive -- that would indicate to users installing
packages from MELPA something along the lines of:

    "We urge the developers of Emacs packages that are in MELPA, or
    that they hope to put in MELPA, to write to emacs-devel@gnu.org
    about signing the legal papers to enable us to include them in
    Emacs or in the Emacs package library."

This message could remain on the screen for a few seconds, or until the user
types something else. The aim is to make people aware of the importance of
this in a gentle way that won't interfere with what they are doing.

First what do people think of such an idea, and second, does it sound like
something anyone would be interesting in adding to package.el, so more people
can learn about how to contribute to ELPA? I have a feeling that a lot of
package authors choose MELPA because the barrier to entry is so low, and they
may not realize how easy it is to get it into Emacs as well.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Adding advisory notification for non-ELPA package.el downloads

[Dmitry Gutov]

Hi John,

On 7/8/17 4:59 AM, John Wiegley wrote:

> First what do people think of such an idea, and second, does it sound like
> something anyone would be interesting in adding to package.el, so more people
> can learn about how to contribute to ELPA?

Doesn't sound great: the message would be shown to the users, and there 
are much more of them than the package developers. It will be a nuisance.

> I have a feeling that a lot of
> package authors choose MELPA because the barrier to entry is so low, and they
> may not realize how easy it is to get it into Emacs as well.

Try asking the MELPA developers about including that paragraph (or a 
modified version) somewhere near the instructions for publishing 
packages to MELPA.

Re: Adding advisory notification for non-ELPA package.el downloads

[Kaushal Modi]

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

On Sat, Jul 8, 2017, 6:29 AM Dmitry Gutov <dgutov@yandex.ru> wrote:

>
> Doesn't sound great: the message would be shown to the users, and there
> are much more of them than the package developers. It will be a nuisance.
>

+1

> I have a feeling that a lot of
> > package authors choose MELPA because the barrier to entry is so low, and
> they
> > may not realize how easy it is to get it into Emacs as well.
>
> Try asking the MELPA developers about including that paragraph (or a
> modified version) somewhere near the instructions for publishing
> packages to MELPA.
>

+1

To add, instead of emailing emacs-devel, we can ask them to email
assign@gnu.org directly.

The instructions can look something like this:

=====
In order to contribute to Emacs (or GNU Elpa, Org-mode, etc), it is
required to assign your copyright to FSF.

You need to send an email to assign@gnu.org asking that you'd like to
assign your copyrights to FSF.

Here's a sample of an email that one can send:

> Hello,

> I visited this site:
https://www.gnu.org/prep/maintain/html_node/Copyright-Papers.html#Copyright-Papers

> I would like to contribute to GNU Emacs.

> What are the copyright papers that I would need to sign?
=====

-- 

Kaushal Modi

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

Re: Adding advisory notification for non-ELPA package.el downloads

[Clément Pit-Claudel]

On 2017-07-07 21:59, John Wiegley wrote:
> I have a feeling that a lot of package authors choose MELPA because 
> the barrier to entry is so low,  and they may not realize how easy it
> is to get it into Emacs as well.

It's not that they doesn't realize how easy it is: it's that it's not easy.

Getting into MELPA requires a writing a one-line Lisp form and submitting it for inclusion.  Getting into ELPA requires subtle git invocations that end up mashing up the history of your project with that of tens of others, while fearing to break the entire ELPA repo because of a missing copyright line in a test file.

And ELPA makes maintaining the package more painful, too: picking out the commits made by others and copying them on your personal repo requires further arcane git invocations — same for importing new commits from your personal repo. And of course you lose other MELPA goodies, like getting download statistics.

For now, the main motivation to publish on ELPA is ideological — not practical. My feeling is that package authors chose not to publish on ELPA because they get all they need from MELPA, for a fraction of the invested time.

Clément.

Re: Adding advisory notification for non-ELPA package.el downloads

[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 goal here is to avoid having packages end up in the situation
Magit is in now.

They get into that situation because developers accept contributions
without thinking of legal papers.  They get contributions from one
person, then another, then another 50 people, then another 50.

The way to avoid this is by showing people what the situation is like
and how they can avoid it.  We need to educate the whole Emacs Lisp
development community.

  > > I have a feeling that a lot of
  > > package authors choose MELPA because the barrier to entry is so low, and they
  > > may not realize how easy it is to get it into Emacs as well.

  > Try asking the MELPA developers about including that paragraph (or a 
  > modified version) somewhere near the instructions for publishing 
  > packages to MELPA.

That notice approach won't be effective, because people would only see
the notice when they have a package ready to use.  That is too late.
We want people to think of this when they START developing the
package.

To inform Emacs users when they load a package from outside ELPA would
be more effective, because they would see it earlier -- well before
they think about putting it in a repository.

That approach would do the job, but it is not perfect.  It is not
perfectly targeted.

Here's an idea that might be better targeted.

The idea is to display a notice when the user edits a file in Emacs
Lisp mode (other than .emacs).  The code could avoid displaying the
notice more than once per week -- using a timestamp for the last time
it was displayed.

To avoid these problems is important.  By comparison, this occasional
small annoyance is a small matter.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Adding advisory notification for non-ELPA package.el downloads

[Jean-Christophe Helary]

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


> On Jul 9, 2017, at 2:03, Richard Stallman <rms@gnu.org> wrote:
> 
> The goal here is to avoid having packages end up in the situation
> Magit is in now.

If ELPA inclusion is as cumbersome as Clement describes it, adding elisp *user* notifications will only upset users and will change little else.

The first thing to do seems to be seriously refine the technical process to have packages included in ELPA. Then we can improve the paper signing system, and then we can embark on a vast campagne to inform MELPA contributors that they can move to ELPA with little extra overhead.

If ELPA is concerned with free software, MELPA seems more inclined to think in terms of "open source software". We can't have people move to free software if oss proves to be less of a hassle (the minority of people who can easily be convinced that free software is better are probably already on ELPA).

Jean-Christophe

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

Re: Adding advisory notification for non-ELPA package.el downloads

[Tim Cross]

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

Totally agree. If we want people to 'do the right thing', we have to make
it as easy as possible. If things are as bad as Clement indicates, nagging
users will have little impact and what impact it does have will likely be
negative.

WRT Richard's suggestion about a weekly notice when editing elisp files -
not sure if it should be all elisp files or whether it should be restricted
to files like *-pkg.el that are part of package.el packages? I do a fair
amount of elisp which does not use package.el, so notices about ELPA are
just annoying. Maybe we could modify package.el to make it mandatory for
packages to include a file/statement which maintainers must include which
requires them to acknowledge the benefits of free software and the
disadvantages of non-ELPA repositories.

Regardless of the approach used, the fundamental requirement will be to
remove all unnecessary barriers to using ELPA and maintaining ELPA
packages.

On 9 July 2017 at 08:12, Jean-Christophe Helary <
jean.christophe.helary@gmail.com> wrote:

>
> On Jul 9, 2017, at 2:03, Richard Stallman <rms@gnu.org> wrote:
>
> The goal here is to avoid having packages end up in the situation
> Magit is in now.
>
>
> If ELPA inclusion is as cumbersome as Clement describes it, adding elisp
> *user* notifications will only upset users and will change little else.
>
> The first thing to do seems to be seriously refine the technical process
> to have packages included in ELPA. Then we can improve the paper signing
> system, and then we can embark on a vast campagne to inform MELPA
> contributors that they can move to ELPA with little extra overhead.
>
> If ELPA is concerned with free software, MELPA seems more inclined to
> think in terms of "open source software". We can't have people move to free
> software if oss proves to be less of a hassle (the minority of people who
> can easily be convinced that free software is better are probably already
> on ELPA).
>
> Jean-Christophe
>



-- 
regards,

Tim

--
Tim Cross

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

Re: Adding advisory notification for non-ELPA package.el downloads

[Dmitry Gutov]

On 7/8/17 8:03 PM, Richard Stallman wrote:

> They get into that situation because developers accept contributions
> without thinking of legal papers.  They get contributions from one
> person, then another, then another 50 people, then another 50.

It's not that serious. Most packages are created and maintained by a 
single developer, with only minor contributions from users.

There are big ones where that's not true, but they older, and they have 
surely considered going the ELPA route already.

> The way to avoid this is by showing people what the situation is like
> and how they can avoid it.  We need to educate the whole Emacs Lisp
> development community.

The nagging approach can just as likely alienate users. We already have 
a lot of those that scoff at the conditions of contributing to Emacs. 
Saying that the hassle is negligible (and saying that often, in users' 
faces) is unlikely to improve the situation.

It's better to work on streamlining the copyright assignment process and 
have a separate campaign (outside of our precious Emacs) to encourage 
developers to do it.

> That notice approach won't be effective, because people would only see
> the notice when they have a package ready to use.  That is too late.
> We want people to think of this when they START developing the
> package.

This distinction doesn't matter much. When someone starts developing a 
package, and until they publish it, they work alone in 99.9% cases.

> To inform Emacs users when they load a package from outside ELPA would
> be more effective, because they would see it earlier -- well before
> they think about putting it in a repository.
> 
> That approach would do the job, but it is not perfect.  It is not
> perfectly targeted.

I think it would be targeted perfectly: "Want to publish a package? 
Here's what you need to do to publish it where *every* Emacs user will 
be able to install it from!"

> Here's an idea that might be better targeted.
> 
> The idea is to display a notice when the user edits a file in Emacs
> Lisp mode (other than .emacs).  The code could avoid displaying the
> notice more than once per week -- using a timestamp for the last time
> it was displayed.

You might want to consider the idea that public relations is not your 
best skill.

Re: Adding advisory notification for non-ELPA package.el downloads

[Yann Hodique]

>>>>> "Clément" == Clément Pit-Claudel <cpitclaudel@gmail.com> writes:

> On 2017-07-07 21:59, John Wiegley wrote:
>> I have a feeling that a lot of package authors choose MELPA because
>> the barrier to entry is so low, and they may not realize how easy it
>> is to get it into Emacs as well.

> It's not that they doesn't realize how easy it is: it's that it's
> not easy.

> Getting into MELPA requires a writing a one-line Lisp form and
> submitting it for inclusion.  Getting into ELPA requires subtle git
> invocations that end up mashing up the history of your project with
> that of tens of others, while fearing to break the entire ELPA repo
> because of a missing copyright line in a test file.

> And ELPA makes maintaining the package more painful, too: picking out
> the commits made by others and copying them on your personal repo
> requires further arcane git invocations — same for importing new
> commits from your personal repo. And of course you lose other MELPA
> goodies, like getting download statistics.

> For now, the main motivation to publish on ELPA is ideological — not
> practical. My feeling is that package authors chose not to publish on
> ELPA because they get all they need from MELPA, for a fraction of the
> invested time.

+1

I'd also like to add a few things:

- some package authors *do not* choose MELPA, MELPA chooses them. Most
  of my packages are in MELPA without me ever asking for it, it's just
  that somebody else cared enough.

- let's not trivialize the act of assigning copyright. It's *not*
  a neutral action (if it was, it wouldn't be required...), and it's
  definitely *not* only about signing some paper. For many people it
  involves researching whether it's actually meaningful or legal to do
  so, depending on their country of citizenship and/or residence. In
  some cases it means selling the idea to their employer (who frequenly
  is the default copyright owner of all their work) which can easily be
  met with scepticism and resistance from legal departments: personally
  it took me more than 2 months to complete that particular
  conversation, just because it's a highly unusual request and people
  didn't understand what was the need.

Bottom-line there are legal implications beyond licensing to doing so
(which is again the whole point), and that can never be as simple as
handling licensing alone. I would consider it quite misleading if those
aspects were glossed over: I fear that would only encourage people to
sign without understanding what it's about.

Proactively contacting elisp developers to ask them if they would
consider a copyright assignment (mentioning the benefit of potential
bundling with Emacs, along with the rest of the implications) seems much
more OK to me.

my 2¢

Yann.

-- 
It is your fate, forgetfulness.  All of the old lessons of life, you lose and 
gain and lose and gain again.

  -- Leto II, the Voice of Dar-es-Balat

Re: Adding advisory notification for non-ELPA package.el downloads

[Chad Brown]

> On 8Jul, 2017, at 17:39, Dmitry Gutov <dgutov@yandex.ru> wrote:
> 
> I think it would be targeted perfectly: "Want to publish a package? Here's what you need to do to publish it where *every* Emacs user will be able to install it from!"

I think Dmitry has a very good idea here: build a mechanism for
publishing elisp packages, incorporate it directly into emacs.
Include in it at least basic support for popular non-ELPA elisp
repositories, even if only as links to external web pages. This is
a good place to include notes about the ELPA process, and it also
provides an interface for starting people on the copyright assignment
process.  (As an aside, the copyright assignment part can probably
also be used for a subsequent “submit a patch to Emacs” elisp
interface.)

~Chad

Re: Adding advisory notification for non-ELPA package.el downloads

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

  > There are big ones where that's not true, but they older, and they have 
  > surely considered going the ELPA route already.

I'm talking about packages that will get into this state in the future,
which at present have just one developer, but will have more.

Maybe that wasn't stated clearly at first.

  > The nagging approach can just as likely alienate users.

A message at most once a week, that is on the screen for a short time,
is hardly "nagging".

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Adding advisory notification for non-ELPA package.el downloads

[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 ELPA inclusion is as cumbersome as Clement describes it, adding
  > elisp *user* notifications will only upset users and will change
  > little else.

We are miscommunicating.  The point of this notice is to teach the
whole community about the need to think about legal papers
from an early stage.

If they have done this, it would eliminate one obstacle to
putting the package in ELPA.  But really it is not about ELPA.

The point is to prevent packages from getting into the problem
situation that Magit is now in.


It sounds like ELPA is very inconvenient to use.  I agree we should
make it easier.  But that's a separate issue.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Adding advisory notification for non-ELPA package.el downloads

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

  > WRT Richard's suggestion about a weekly notice when editing elisp files -
  > not sure if it should be all elisp files or whether it should be restricted
  > to files like *-pkg.el that are part of package.el packages?

This is not really about the activity of preparing a package.  The
point is to educate the community to think about legal papers when
they start to accept contributions to their packages from other
developers.

If people generally incorporate contributions from lots of other
people first, and only then prepare a package, then attaching this
notice to editing *-pkg.el would show it to them too late.

However, if people generally prepare a package first, and get offered
contributions afterward, then maybe attaching this notice to editing
*-pkg.el is a very good idea.

Which way do those things generally happen nowadays?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Adding advisory notification for non-ELPA package.el downloads

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

  > Proactively contacting elisp developers to ask them if they would
  > consider a copyright assignment (mentioning the benefit of potential
  > bundling with Emacs, along with the rest of the implications) seems much
  > more OK to me.

That would entail searching for people who are just starting packages
and sending each one mail.  I agree it would give better results -- if
we could do it.  But it would be a lot of work.  Who would do the
work?  And how would we find people that are just starting
to get contributions to their packages?

It isn't better if it isn't feasible.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Adding advisory notification for non-ELPA package.el downloads

[Dmitry Gutov]

On 7/10/17 12:27 PM, Richard Stallman wrote:

> I'm talking about packages that will get into this state in the future,
> which at present have just one developer, but will have more.

These can be well served by having the discussed call to action 
somewhere near (before or after) MELPA package publishing instructions.

> Maybe that wasn't stated clearly at first.

It was. And I believe I've addressed it already.

>    > The nagging approach can just as likely alienate users.
> 
> A message at most once a week, that is on the screen for a short time,
> is hardly "nagging".

It's an ill-defined task, at best. Which files, when, where to store the 
last message date? Will it distract the user from writing code (will it 
make the buffer contents jump)? How will it deal with personal 
configurations (which people have no intention of publishing), and will 
it continue to show those messages even after the package is published?

Re: Adding advisory notification for non-ELPA package.el downloads

[Ken Manheimer]

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

On Mon, Jul 10, 2017 at 5:27 AM, Richard Stallman <rms@gnu.org> wrote:

> [...]
>   > The nagging approach can just as likely alienate users.
>
> A message at most once a week, that is on the screen for a short time,
> is hardly "nagging".


That's a misleading way to think about it. If every major facility on a
machine was nonchalant about some random once-per-week notification, you
could potentially have several to hundreds per day. (I sometimes feel like
it's towards the more extreme end on the rare occasions that I fire up
Windows machines.) Righteous as the specific purpose might or might not be,
it will be another interruption in the escalating battle for users stray
attention, in which users are the losers.

A properly targeted notification is delivered when someone is initiating
actions specifically for the purpose that the notification addresses. I'm
not sure where that would be in this case, but hearing "once per week"
suggests to me that it's randomly targeted, as part of an activity that
sometimes and sometimes doesn't include the specific activity.

Ken

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

Re: Adding advisory notification for non-ELPA package.el downloads

[Ken Manheimer]

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

On Mon, Jul 10, 2017 at 5:29 AM, Richard Stallman <rms@gnu.org> 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. ]]]
>
>   > Proactively contacting elisp developers to ask them if they would
>   > consider a copyright assignment (mentioning the benefit of potential
>   > bundling with Emacs, along with the rest of the implications) seems
> much
>   > more OK to me.
>
> That would entail searching for people who are just starting packages
> and sending each one mail.  I agree it would give better results -- if
> we could do it.  But it would be a lot of work.  Who would do the
> work?  And how would we find people that are just starting
> to get contributions to their packages?
>

This is starting to zero in on a specific activity where informing the user
about the ELPA process would be appropriate.

How about enlisting the support of the various package repositories (MELPA
and etc.), so they provide notices to people establishing packages that the
additional steps to include their package in ELPA, including doing their
own copyright assignment and prompting their (prospective) contributors for
copyright assignment early on in the process, is good for Emacs and for
their packages...


> It isn't better if it isn't feasible.
>

The approach you proposed is only one option, there are others.

Ken


>
> --
> Dr Richard Stallman
> President, Free Software Foundation (gnu.org, fsf.org)
> Internet Hall-of-Famer (internethalloffame.org)
> Skype: No way! See stallman.org/skype.html.
>
>
>

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

Re: Adding advisory notification for non-ELPA package.el downloads

[Yann Hodique]

>>>>> "Richard" == 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. ]]]

>> Proactively contacting elisp developers to ask them if they would
>> consider a copyright assignment (mentioning the benefit of potential
>> bundling with Emacs, along with the rest of the implications) seems much
>> more OK to me.

> That would entail searching for people who are just starting packages
> and sending each one mail.  I agree it would give better results -- if
> we could do it.  But it would be a lot of work.  Who would do the
> work?  And how would we find people that are just starting
> to get contributions to their packages?

> It isn't better if it isn't feasible.

Well, one possibility would be to:

1. figure out where most of the code that ends up in MELPA lives (since
   it seems to be the target so far):

   ~/src/github.com/melpa/melpa/recipes master
   ❯ grep :fetcher * | sed 's/.*:fetcher \([a-z]*\).*/\1/' | sort | uniq -c | sort -rg
   3393 github
    156 wiki
     44 git
     38 bitbucket
     26 gitlab
      9 svn
      4 cvs
      2 darcs
      2 bzr
      1 hg

   given that the wiki data is reachable from github (via
   https://github.com/emacsmirror/emacswiki.org) that means that at
   least 96.6% of the target is present on github one way or the
   other. I'm too lazy to extract real trends, but this share is
   slowly growing
   
   | 07/2012 | 07/2013 | 07/2014 | 07/2015 | 07/2016 | 07/2017 |
   |---------+---------+---------+---------+---------+---------|
   |    89.8 |    92.4 |      94 |    95.8 |    96.5 |    96.6 |

2. use the fact that github data is published weekly as a BigQuery
   dataset (https://cloud.google.com/bigquery/public-data/github) to
   perform fancy queries on it: like what are the emacs repositories
   that went from 1 contributor last week to 2 contributors this week,
   crosscheck with paperwork data and identify who to go after next.
   An example of what has already been achieved using those tools:
   https://kozikow.com/2016/06/29/top-emacs-packages-used-in-github-repos/

That's kind of handwavy and vaguely creepy (then again, any kind of
automatic detection of what I might be doing to "help me being a better
member of the community" is gonna creep me out no matter what), but most
of the data is definitely readily available.

Yann.

-- 
The worst sort of protection is confidence.  The best defense is suspicion.

  -- HASIMIR FENRING

Re: Adding advisory notification for non-ELPA package.el downloads

[Joost Kremers]

On Sat, Jul 08 2017, Clément Pit-Claudel wrote:
> On 2017-07-07 21:59, John Wiegley wrote:
>> I have a feeling that a lot of package authors choose MELPA 
>> because 
>> the barrier to entry is so low,  and they may not realize how 
>> easy it
>> is to get it into Emacs as well.
>
> It's not that they doesn't realize how easy it is: it's that 
> it's not easy.
>
> Getting into MELPA requires a writing a one-line Lisp form and 
> submitting it for inclusion.  Getting into ELPA requires subtle 
> git invocations that end up mashing up the history of your 
> project with that of tens of others, while fearing to break the 
> entire ELPA repo because of a missing copyright line in a test 
> file.
>
> And ELPA makes maintaining the package more painful, too: 
> picking out the commits made by others and copying them on your 
> personal repo requires further arcane git invocations — same for 
> importing new commits from your personal repo. And of course you 
> lose other MELPA goodies, like getting download statistics.
>
> For now, the main motivation to publish on ELPA is ideological — 
> not practical. My feeling is that package authors chose not to 
> publish on ELPA because they get all they need from MELPA, for a 
> fraction of the invested time.

Let me just say 'hear, hear' to that, as one of those typical 
package maintainers. I thought about using ELPA instead of MELPA a 
few times, but reading such comments as "arcane git commands", 
"mashing up your history" and "breaking the entire ELPA repo", my 
immediate reaction is "oh well, some other time, perhaps". 

I should probably point out that my git skill level is low, and 
while I'd be willing to learn more, the time investment if often 
prohibitive. (I'm not a professional programmer, just a guy with a 
hobby.) With MELPA, that's sufficient, though, and Github has a 
lot of help pages that provide clear and concise instructions for 
things I don't do every day, such as dealing with PRs or keeping a 
fork up-to-date with its upstream repo.

I've just been skimming the GNU ELPA README on 
http://git.savannah.gnu.org/cgit/emacs/elpa.git/plain/README and 
although it *looks* like once thing's are set up, I shouldn't have 
to do much more than a git push to update my package, the process 
of getting there seems quite involved.

More importantly perhaps, the entire workflow seems to be 
different. With MELPA, I put my code in a publicly accessible repo 
that I create myself, on a service of my own choosing (in my case 
Github), and then tell MELPA where to look for it. With GNU ELPA, 
it seems I need to put my code somewhere specific, and it's not in 
a repo that I create or own.

In itself, it's not a big problem that GNU ELPA uses a different 
workflow from MELPA, but, speaking for myself, it would be good if 
the ELPA README (or some other document) would contain a few 
paragraphs explaining the differences and would cover the steps 
involved in such a way that they make sense for someone with a 
less-than-stellar understanding of git.

Anyway, just my two €0.02.


-- 
Joost Kremers
Life has its moments

Re: Adding advisory notification for non-ELPA package.el downloads

[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 starting to zero in on a specific activity where informing the user
  > about the ELPA process would be appropriate.

"The ELPA process" gives the wrong idea.  This is the process for making
a package that CAN easily be integrated into Emacs, or ELPA.
-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Adding advisory notification for non-ELPA package.el downloads

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

  > That's a misleading way to think about it. If every major facility on a
  > machine was nonchalant about some random once-per-week notification, you
  > could potentially have several to hundreds per day.

There is no reason to worry about an implausible extrapolation of what
we are planning.

It's not just unlikely, it's mathematically implausible because
it assumes the person uses thousands of major facilities.
I doubt I use even a hundred.

Anyway, it will be easy to turn off these notices if you want to.
So the problem is imaginary.

In fact, people don't mind notices so much anyway.

Some programs offer hints each time they start, and you have to click
to make them go away.  For instance, Audacity does this.  It offers
a way to turn them off, but I never bothered to do that.

I don't think this issue amounts to a real problem.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Adding advisory notification for non-ELPA package.el downloads

[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's an ill-defined task, at best.

That's not a problem.  We're talking about communicating an idea to
people.

				       Which files, when, where to store the 
  > last message date? Will it distract the user from writing code (will it 
  > make the buffer contents jump)?

These are technical details that I am sure we will handle.  Since
you don't need to do the work, don't make a fuss about it.

There will be a setting to turn off the messages.  Once you know the
point we want to show people, shut off the message if you like.

				    How will it deal with personal 
  > configurations (which people have no intention of publishing), and will 
  > it continue to show those messages even after the package is published?

I see a misunderstanding.  This is not a question of "dealing with"
individual packages one by one.  The goal is to make sure people are
aware of the importance of getting legal papers as they accept
contributions.

The idea of doing this in specific situations (maybe editing Elisp
files, maybe editing package files) is to identify the people it is
useful to inform: people who are developing Emacs packages.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Adding advisory notification for non-ELPA package.el downloads

[Yuri Khan]

On Tue, Jul 11, 2017 at 6:45 PM, Richard Stallman <rms@gnu.org> wrote:

> I see a misunderstanding.  This is not a question of "dealing with"
> individual packages one by one.  The goal is to make sure people are
> aware of the importance of getting legal papers as they accept
> contributions.

I’d like to voice several ideas related to attracting users and
developers and raising awareness of the Emacs contribution policy.

1. Emacs has a web site at <https://www.gnu.org/software/emacs/>. At
the same time, the emacs.org domain name, although under control of
FSF, stands unused.

**Suggestion:** Make https://emacs.org/ the official site of Emacs. Or
at least set up redirection from ^https://emacs\.org/\(.*\)$ to
https://www.gnu.org/software/emacs/\1.


2. The Emacs web site has a two-line menu, but no “Contributing” item
in that menu. One has to go through “Documentation & Support”, then
the Reporting Bugs subheading, then actually read the first paragraph
of that section, which sends them to the CONTRIBUTE file, which is a
literal plain text copy of that file from the source tree. That file
goes on to tell a lot of technical things about the development
process, but does not mention copyright assignment paperwork except in
passing in the section about commit messages.

**Suggestions:**

* Add an actual “Contributing” page to the Emacs web site, and a link
to that page to the site menu.

* That page should be an attractively formatted web page, not a plain
text file with Org markup.

* It should be reasonably short, have clear structure, and might link
to sub-pages for detailed explanations.

* Copyright assignment should be discussed early in that page. It
should explain the benefit of copyright assignment concisely,
convincingly, and *in terms of the contributor*. (As in, “If you
assign copyright to us, we will defend it on your behalf against evil
corporations that are out there to parasitize on your work”.)
Alternatives should also be explored, with explanations how choosing a
different path is bad for *the contributor* as well as the community.


3. The ELPA site, <http://elpa.gnu.org/>, says this near the bottom of
the home page: “To contribute new packages refer to the README”, where
README is a link to another Org-like plain text file that discusses
technicalities without mentioning copyright paperwork.

**Suggestions:**

* Make that README an attractively formatted, well-structured web page
or a collection of pages.

* Explain copyright assignment and alternatives there, too.


4. The MELPA site is not your competitor. It is there to fill a need,
both for users and package authors.

**Suggestion:** Place a short notice there, to the effect of “Wouldn’t
it be great if your package were accepted into ELPA? Consider this…”
with a short explanation of the prerequisites and a link to the ELPA
site.

Improving GNU ELPA (was: Adding advisory notification for non-ELPA package.el downloads)

[Stefan Monnier]

> for inclusion.  Getting into ELPA requires subtle git invocations that end
> up mashing up the history of your project with that of tens of others, while
> fearing to break the entire ELPA repo because of a missing copyright line
> in a test file.
> And ELPA makes maintaining the package more painful, too: picking out the
> commits made by others and copying them on your personal repo requires
> further arcane git invocations — same for importing new commits from your
> personal repo. And of course you lose other MELPA goodies, like getting
> download statistics.

While most of the above only applies to the case where you put your
package as a "subtree" rather than an "external", I can't say that the
criticism is unfair.

And I indeed think that if we want to expand the use of ELPA, the
proverbial someone should first work on the elpa.gnu.org infrastructure.
It's all a simple matter of writing scripts, really, so help is very
welcome.

I know of the following:
- when someone commits to elpa.git we get an elpa-diffs email which
  I used to then forward to the corresponding package maintainer.
  This forwarding is currently broken because of changes to my
  email server.  This should really be done in elpa.gnu.org instead of
  iro.umontreal.ca anyway, so I don't intend to fix the old setup.

- elpa.gnu.org should be notified (e.g. via the elpa-diffs thingy)
  whenever a commit is made to an elpa package, and should then build
  the corresponding package (if the version was changed).  Currently, we
  just rebuild the world blindly twice a day, which is both more costly
  and adds a ~6h delay.  More importantly, this will make the handling
  of "externals" just as efficient as "subtrees", so it will scale
  a lot better.

- once that's in place, we could also consider supporting "one
  repository per package" rather than "one branch per package".

- we have the web-server log, so we could provide download stats.

Publishing on GNU ELPA is inevitably more work than on MELPA:
- you need to sign paperwork.
- we don't want to fetch from non-GNU servers, so we need the maintainer
  to push to elpa.git explicitly.
- we want the elpa.git code to be writable by "Emacs maintainers", so
  the package's maintainer will sometimes have to deal with commits made
  outside of his control.

But we could tilt the balance the other way.  The way I see GNU ELPA,
it doesn't just provide package distribution but also package hosting,
so we could maybe move towards a gitea/gogs/gitlab/younameit system
for it.  We could add some wiki or some way for users to vote up/down
and add comments to each package, ...

IOW, elpa.gnu.org needs some tender love from someone who understands
the web.  So far I've been doing most of the maintenance and I don't
understand the web, really.


        Stefan

Re: Adding advisory notification for non-ELPA package.el downloads

[John Wiegley]

>>>>> "YK" == Yuri Khan <yuri.v.khan@gmail.com> writes:

KY> 1. Emacs has a web site at <https://www.gnu.org/software/emacs/>. At the
KY> same time, the emacs.org domain name, although under control of FSF,
KY> stands unused.

That's excellent; I didn't realize Toby had given up the domain to the FSF! We
should definitely put it to use.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Adding advisory notification for non-ELPA package.el downloads

[Yuri Khan]

On Wed, Jul 12, 2017 at 1:01 AM, John Wiegley <jwiegley@gmail.com> wrote:
>>>>>> "YK" == Yuri Khan <yuri.v.khan@gmail.com> writes:
>
> KY> 1. Emacs has a web site at <https://www.gnu.org/software/emacs/>. At the
> KY> same time, the emacs.org domain name, although under control of FSF,
> KY> stands unused.
>
> That's excellent; I didn't realize Toby had given up the domain to the FSF! We
> should definitely put it to use.

Okay, I was unaware that the transfer happened less than a month ago.
Google cache says emacs.org was under control of John Toby Knudsen on
2017-05-13.

In that case, I understand why emacs.org is not the official site of
Emacs, but the suggestion still stands.

Re: Adding advisory notification for non-ELPA package.el downloads

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

  > **Suggestion:** Make https://emacs.org/ the official site of Emacs.

To do that, we would have to set up so the GNU Project and Emacs developers
can edit it.  THat would take our sysadmins more time than we want to
lose from other work.

									Or
  > at least set up redirection from ^https://emacs\.org/\(.*\)$ to
  > https://www.gnu.org/software/emacs/\1.

That would be easy.  Does anyone see a problem with this?  If not,
I will ask the sysadmins to do it.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Adding advisory notification for non-ELPA package.el downloads

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

  > 2. The Emacs web site

You mean /software/emacs, right?  I would call that a directory,
not a web site.

			  has a two-line menu, but no “Contributing” item
  > in that menu. One has to go through “Documentation & Support”, ...

These suggestions make sense to me.

Nicolas Petton maintains those pages, I believe.
If he likes these ideas, would people like to help him implement them?

  > 3. The ELPA site, <http://elpa.gnu.org/>, says this near the bottom of
  > the home page: “To contribute new packages refer to the README”, where
  > README is a link to another Org-like plain text file that discusses
  > technicalities without mentioning copyright paperwork.

  > **Suggestions:**

  > * Make that README an attractively formatted, well-structured web page
  > or a collection of pages.

  > * Explain copyright assignment and alternatives there, too.

These are good ideas.  Don't the Emacs maintainers maintain that site?

  > 4. The MELPA site is not your competitor. It is there to fill a need,
  > both for users and package authors.

I will be talking with them when I'm sure of what to say.


-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Adding advisory notification for non-ELPA package.el downloads

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

  > In itself, it's not a big problem that GNU ELPA uses a different 
  > workflow from MELPA, but, speaking for myself, it would be good if 
  > the ELPA README (or some other document) would contain a few 
  > paragraphs explaining the differences and would cover the steps 
  > involved in such a way that they make sense for someone with a 
  > less-than-stellar understanding of git.

I agree.  I encourage the people who manage ELPA to do this.

  > With MELPA, I put my code in a publicly accessible repo 
  > that I create myself, on a service of my own choosing,
  > and then tell MELPA where to look for it.

Is there any reason we should not do this on ELPA?

If the repo that ELPA copies from is fully under the control
of the developer of that package, I don't see that it
matters greatly whether the developer installs
changes into that package via ELPA directly, or into some
other repo which then gets copied wholesale to ELPA.

ELPA managers, does the act of installing directly into ELPA give us
an opportunity to make sure something is being handled right?

  > (in my case Github)

If only the developer uses that repo system, we don't
have to be concerned with what system it is.

But if other contributors are going to be directed
to that other repo system, we would want it not to be Github.
(See https://gnu.org/software/repo-criteria.html.)


-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Adding advisory notification for non-ELPA package.el downloads

[Stefan Monnier]

> ELPA managers, does the act of installing directly into ELPA give us
> an opportunity to make sure something is being handled right?

I think the difference is pretty significant, yes.
If we pull from other repositories:
- maintainers of the package will not be reminded that the package is
  also in GNU ELPA (and should hence adhere to a copyright assignment
  policy).

- While the repository may be under the sole control of the package
  maintainer when the package is added to GNU ELPA, that can and will
  evolve over time, completely outside of our control.

- There is no easy way for us (Emacs maintainers) to install fixes to
  adapt to changes in Emacs.  More specifically, it needs to be done by
  hand package-by-package, by submitting a patch and hoping the upstream
  maintainer is still listening.

- Handling old unmaintained packages is more trouble.

- We won't get elpa-diffs email, where we have the opportunity to give
  advice on coding style and have a minimum amount of review of the code
  we end up distributing.

Basically it would turn GNU ELPA into a pure distribution site, with
very little control over what we distribute, including the copyright
status of what we distribute.

The only real difference with MELPA would be that we could check that
each file comes with the proper GPLv3+ blurb.  Not sure if it would be
worth the trouble.


        Stefan

Re: Improving GNU ELPA

[Clément Pit-Claudel]

On 2017-07-11 12:04, Stefan Monnier wrote:
> - we don't want to fetch from non-GNU servers, so we need the maintainer
>   to push to elpa.git explicitly.

Not really (I think you hint at this a bit later): if the FSF hosts a gitlab instance, or any sort of (multi-repo) git hosting, then developers could just mirror their repos to that instance.

And in fact we already have this.  ELPA could work just like MELPA, but restricting the package source to Savannah.  Then publishing to ELPA would be just like MELPA, except for having to mirror to Savannah from time to time.

Clément.

Re: Improving GNU ELPA

[Stefan Monnier]

>> - we don't want to fetch from non-GNU servers, so we need the maintainer
>> to push to elpa.git explicitly.
>
> Not really (I think you hint at this a bit later): if the FSF hosts a gitlab
> instance, or any sort of (multi-repo) git hosting, then developers could
> just mirror their repos to that instance.

Indeed, by "elpa.git" I really meant "some repository under our
control".  Currently it's elpa.git, but that could be expanded.

> And in fact we already have this.  ELPA could work just like MELPA, but
> restricting the package source to Savannah.  Then publishing to ELPA would
> be just like MELPA, except for having to mirror to Savannah from time
> to time.

Note that allowing any package on Savannah would already be quite
different, since people without copyright papers have write access to it
(and we'd lose the write access for Emacs maintainers, as well as the
elpa-diffs reviews, ...).

I guess it would be marginally better than allowing any package from
"anywhere" (e.g. when a package goes unmaintained, there's a process
that could allow us to get write access), but it would add the hurdle of
being accepted into Savannah, so I don't think it would eliminate enough
friction to make a significant difference.


        Stefan


PS: BTW, to clarify my position: if it were up to me, I'd get rid of the
    copyright assignment policy for GNU ELPA (and for Emacs as well,
    while we're at it), but I'd keep the "locally hosted in a repository
    to which we have write access, with commit-diffs".

Re: Adding advisory notification for non-ELPA package.el downloads

[Yuri Khan]

On Wed, Jul 12, 2017 at 5:57 AM, Richard Stallman <rms@gnu.org> 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. ]]]
>
>   > **Suggestion:** Make https://emacs.org/ the official site of Emacs.
>
> To do that, we would have to set up so the GNU Project and Emacs developers
> can edit it.  THat would take our sysadmins more time than we want to
> lose from other work.

That doesn’t have to be hard. Likely, both sites can be served by the
same machine from the same directory.

Assuming the whole //gnu.org/software/emacs subtree is served as
static files and contains no relative links outside that subtree:

* Add a DNS entry for emacs.org pointing to the same IP address as gnu.org.

* On that machine, add a virtual host named "emacs.org" to the web
server configuration, rooted at the software/emacs subdirectory of the
main site root.

Functionally, that is all; for search engine optimization purposes, it
may be desirable to also configure both locations to add an HTTP
header of the form

Link: <https://emacs.org/{subpath}>; rel="canonical"

so that search engines know the two locations are equivalent and don’t
show both in search results.

Re: Adding advisory notification for non-ELPA package.el downloads

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

  > Assuming the whole //gnu.org/software/emacs subtree is served as
  > static files and contains no relative links outside that subtree:

  > * Add a DNS entry for emacs.org pointing to the same IP address as gnu.org.

  > * On that machine, add a virtual host named "emacs.org" to the web
  > server configuration, rooted at the software/emacs subdirectory of the
  > main site root.

I will suggest doing that.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Adding advisory notification for non-ELPA package.el downloads

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

  > - maintainers of the package will not be reminded that the package is
  >   also in GNU ELPA (and should hence adhere to a copyright assignment
  >   policy).

  > - While the repository may be under the sole control of the package
  >   maintainer when the package is added to GNU ELPA, that can and will
  >   evolve over time, completely outside of our control.

  > - There is no easy way for us (Emacs maintainers) to install fixes to
  >   adapt to changes in Emacs.  More specifically, it needs to be done by
  >   hand package-by-package, by submitting a patch and hoping the upstream
  >   maintainer is still listening.

  > - Handling old unmaintained packages is more trouble.

One way to prevent these problems is by insisting they give the Emacs
maintainers administrative access to the real package repository.
Then we could install notices about legal papers, take action if
non-signers have write access, install fixes, and handling old
unmaintained packages with little more trouble than they are now.


  > - We won't get elpa-diffs email, where we have the opportunity to give
  >   advice on coding style and have a minimum amount of review of the code
  >   we end up distributing.

That would be a loss, but can we install another system to send diff
mail?  It could operate on a clone of the real package repository.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

emacs.org website [was Re: Adding advisory notification for non-ELPA package.el downloads]

[Glenn Morris]

Yuri Khan wrote:

> Assuming the whole //gnu.org/software/emacs subtree is served as
> static files 

Yes, AFAIK.

> and contains no relative links outside that subtree:

No; it does contain links to other pages on gnu.org. (Many of these are
set up through the .htaccess files.)

emacs.org website [was Re: Adding advisory notification for non-ELPA package.el downloads]

[Glenn Morris]

Richard Stallman wrote:

> I will suggest doing that.

Before you ask people to do work, I'd encourage you to explore what
the options are, what the consequences would be, and what the people
who maintain Emacs and its website think (if that's a factor; this
topic is currently buried in a long unrelated thread). There seem to
be various options:

1) Make emacs.org the canonical Emacs homepage address. This would be a
fair bit of work to update all the links that exist in Emacs and
elsewhere (obviously there would be a redirect from the old site, but
you'd still want links updated). IMO such a move would de-emphasize the
relation to GNU.

2) Make emacs.org a duplicate of gnu.org/s/emacs. Requires some work
on the current site contents, which assume a gnu.org address.
Frankly I don't see the benefit of this approach.

3) Redirect emacs.org to gnu.org/s/emacs. Easy. May as well.

Obviously I'm not the target of this proposal, since I don't care what
URL I use to access a site, unless it's very long, and gnu.org/s/emacs
is short enough for me.

Re: Adding advisory notification for non-ELPA package.el downloads

[Nicolas Petton]

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

Richard Stallman <rms@gnu.org> writes:

> These suggestions make sense to me.
>
> Nicolas Petton maintains those pages, I believe.
> If he likes these ideas, would people like to help him implement them?

They also make sense to me, I could implement them if people think they
make sense.

>   > 3. The ELPA site, <http://elpa.gnu.org/>, says this near the bottom of
>   > the home page: “To contribute new packages refer to the README”, where
>   > README is a link to another Org-like plain text file that discusses
>   > technicalities without mentioning copyright paperwork.
>
>   > **Suggestions:**
>
>   > * Make that README an attractively formatted, well-structured web page
>   > or a collection of pages.
>
>   > * Explain copyright assignment and alternatives there, too.
>
> These are good ideas.  Don't the Emacs maintainers maintain that site?

I revamped this website some months ago, and I also think it's a good
idea.

Cheers,
Nico

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

Re: Improving GNU ELPA

[Nicolas Petton]

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

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

Salut Stefan,

> PS: BTW, to clarify my position: if it were up to me, I'd get rid of the
>     copyright assignment policy for GNU ELPA (and for Emacs as well,
>     while we're at it)

Je voudrais comprendre pourquoi tu penses ça.  Tu peux m'expliquer ? (ou
répondre sur la mailing-list si tu préfères).

Nico

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

Re: Improving GNU ELPA

[Stefan Monnier]

>> PS: BTW, to clarify my position: if it were up to me, I'd get rid of the
>> copyright assignment policy for GNU ELPA (and for Emacs as well,
>> while we're at it)
> Je voudrais comprendre pourquoi tu penses ça.
> Tu peux m'expliquer ?

Je ne pense pas que ça en vaut la peine: le gain est négligeable
comparé au coût.

> (ou répondre sur la mailing-list si tu préfères).

Je ne pense pas que ce soit utile d'en discuter, parce que la position
de Richard est ferme là dessus à ma connaissance (et c'est bien trop mineur
pour mériter un fork).


        Stefan

Re: Improving GNU ELPA

[Stefan Monnier]

Duh!  And here I am posting to the list that which I didn't want!
Please don't respond!


        Stefan

Re: emacs.org website [was Re: Adding advisory notification for non-ELPA package.el downloads]

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

  > 3) Redirect emacs.org to gnu.org/s/emacs. Easy. May as well.

I too think that is best.  I don't know how such redirects work, so am
not sure if that is really different from the previous suggestion.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Adding advisory notification for non-ELPA package.el downloads

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

  > >   > **Suggestions:**
  > >
  > >   > * Make that README an attractively formatted, well-structured web page
  > >   > or a collection of pages.
  > >
  > >   > * Explain copyright assignment and alternatives there, too.

Who would like to implement these suggested communications in ELPA
itself?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Adding advisory notification for non-ELPA package.el downloads

[Jean Louis]

On Sun, Jul 09, 2017 at 08:50:53AM +1000, Tim Cross wrote:
> Totally agree. If we want people to 'do the
> right thing', we have to make it as easy as
> possible. If things are as bad as Clement
> indicates, nagging users will have little impact
> and what impact it does have will likely be
> negative.
> 
> WRT Richard's suggestion about a weekly notice
> when editing elisp files - not sure if it should
> be all elisp files or whether it should be
> restricted to files like *-pkg.el that are part
> of package.el packages? I do a fair amount of
> elisp which does not use package.el, so notices
> about ELPA are just annoying. Maybe we could
> modify package.el to make it mandatory for
> packages to include a file/statement which
> maintainers must include which requires them to
> acknowledge the benefits of free software and
> the disadvantages of non-ELPA repositories.

What developers of GNU Emacs could do is to have
yet another HELP menu item, "How to contribute",
where the full instructions and updated file may
be displayed in the manner of Emacs News or "How
to display bugs".

The menu "How to contribute" should be there all
the time.

I do not think that users editing *.el files shall
be bothered.

But they can be bothered on the Splash screen
which could link to "How to contribute" file and
on other screns, there could be link to "How to
contribute".

Same links could explain the problem with
copyrights and proper assignments.

And the same section could be included in Emacs
Lisp and Emacs manuals.

That way larger number of people would understand
that they can directly contribute and they would
have not just a short notice, but full
explanation.

Jean Louis

Re: Adding advisory notification for non-ELPA package.el downloads

[Nicolas Petton]

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

Richard Stallman <rms@gnu.org> writes:

> Who would like to implement these suggested communications in ELPA
> itself?

What do you mean by "in ELPA itself"?

Nico

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

Re: Improving GNU ELPA

[Etienne Prud’homme]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> PS: BTW, to clarify my position: if it were up to me, I'd get rid of the
>     copyright assignment policy for GNU ELPA (and for Emacs as well,
>     while we're at it), but I'd keep the "locally hosted in a repository
>     to which we have write access, with commit-diffs".

For one thing we can all agree that the bureaucracy isn’t what we would
expect for free (libre) software.  Free software should be easy to
modify and contribute.

Given that the process has been criticized as been both hard to
understand and burdensome for new contributors, we need to find a
solution for newcomers to understand the reason and process of doing
such things.

I think people are right in saying that a text file and a legal paper
describing the need for copyright assignment is not sufficient.  We
really need a way to describe the process in a simple and clear
interface.  That’s what I see is most needed in either Emacs or ELPA.

So here’s my proposal:

Making a web application for describing the need and the process of the
paperwork.  I mean by that a simple 3-4 clicks process.

1. show major reasons why we ask that.

2. a menu list to choose the country the person lives in.  Depending on
   the country requirements, we would show how to make a valid copyright
   assignment.

  2a. if the country allow to filling an online form, show a form to
      assign copyright to the FSF.

  2b. if the country allow copyright assignment with a signature, allow
      the user to sign electronically (either using mouse or signature
      picture).  I’ve signed a Non Disclosure Agreement using my mouse
      in the past for a US company.

  2c. if the country doesn’t allow electronic signature, allow printing
      the document and explaining how to scan it (some people have no
      idea a phone can do the job).
 
  2d. if the country does require paper with ink, automatically generate
      the document to be printed and signed.  Also display information
      on how to post it to the copyright holder.

3. validate the information to send and that the employer would allow
   such thing.  In case the work might be done on the company’s time,
   ask a confirmation from the company (similar to step 2).

4. confirm the copyright assignment.

  4a. if no signature is needed, confirm to the user the copyright
      assignment.

  4b. if a signature is needed, we might need to verify it.  I know some
      countries don’t require it.

  4c. make an assignment ticket in case we need material paper.  Once we
      receive, we will notify the user.

All of those things could be done from the web browser (and also from
Emacs).  We could make a web application for that that could be used by
other projects.  A copyright assignment could be done in 5min.

That was my two cons cells.

--
Etienne

Re: Improving GNU ELPA

[Phillip Lord]

Etienne Prud’homme <e.e.f.prudhomme@gmail.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> PS: BTW, to clarify my position: if it were up to me, I'd get rid of the
>>     copyright assignment policy for GNU ELPA (and for Emacs as well,
>>     while we're at it), but I'd keep the "locally hosted in a repository
>>     to which we have write access, with commit-diffs".
>
> Making a web application for describing the need and the process of the
> paperwork.  I mean by that a simple 3-4 clicks process.

A web interface with an current status and easy navigation would be a
great addition, I think.


> 3. validate the information to send and that the employer would allow
>    such thing.  In case the work might be done on the company’s time,
>    ask a confirmation from the company (similar to step 2).

It's irrelevant when the work is done unfortunately. If you are employed
as a programmer, then a priori your employer has a strong claim on the
copyright of any code you right.

So, you have to get a disclaimer. This is one of those things that can
take quite a while, especially if you work for a big company.


> All of those things could be done from the web browser (and also from
> Emacs).  We could make a web application for that that could be used by
> other projects.  A copyright assignment could be done in 5min.

It's worth a try for sure!

Phil

Re: Adding advisory notification for non-ELPA package.el downloads

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

  > > Who would like to implement these suggested communications in ELPA
  > > itself?

  > What do you mean by "in ELPA itself"?

Someone proposed making these changes in ELPA, in its web pages, and
repo.  They would be changes in ELPA itself.

Would someone like to implement them (in ELPA)?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: emacs.org website [was Re: Adding advisory notification for non-ELPA package.el downloads]

[John Wiegley]

>>>>> "RS" == Richard Stallman <rms@gnu.org> writes:

RS> I too think that is best. I don't know how such redirects work, so am not
RS> sure if that is really different from the previous suggestion.

We just need a webserver, on the machine pointed to by emacs.org, to accept
incoming requests on port 80 for that IP address, and transparently redirect
them to the target URL.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Improving GNU ELPA (was: Adding advisory notification for non-ELPA package.el downloads)

[Jonas Bernoulli]

I think we should keep requiring authors to push to and pull from Elpa,
that is not really the issue.  The issue as I see it is that doing so is
not as easy as:

  git pull elpa
  git push elpa

Instead one has to do something like (provided one does actually care
about the history in both the "personal" and the Elpa repository staying
clean).

* Integrating Elpa changes.

  git fetch elpa
  git filter-branch
  git branch -f elpa &&
  git filter-branch -f --subdirectory-filter "packages/$package" --commit-filter '
  # One could use "--prune-empty" instead, but this script is better.
  test $# = 1 && test -z "$(git ls-tree $1)" && skip_commit "$1" && exit
  args="$@"
  tree="$1"
  shift
  while test -n "$1"
  do
	shift
	test "$tree" = $(git rev-parse "$1^{tree}") && map "$1" && exit
	shift
  done
  git commit-tree $args' elpa

So I think the focus should be on enabling "one repository per package"
instead of making Elpa pull.  If pushing to Elpa was as easy as for normal
Git repositories, then people would not mind.

  Jonas

Re: Improving GNU ELPA

[Stefan Monnier]

>   git fetch elpa
>   git filter-branch

That's only for the "subtree" packages.  You can use an "external"
package, in which case the package has its own branch.

> So I think the focus should be on enabling "one repository per package"

One repository per package would be a bit more convenient in some cases,
admittedly, but one branch per package is not that bad.


        Stefan

Re: Improving GNU ELPA

[Jonas Bernoulli]

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

>>   git fetch elpa
>>   git filter-branch
>
> That's only for the "subtree" packages.  You can use an "external"
> package, in which case the package has its own branch.
>
>> So I think the focus should be on enabling "one repository per package"
>
> One repository per package would be a bit more convenient in some cases,
> admittedly, but one branch per package is not that bad.

That works for me, and I suspect for many others too.

I was somehow under the impression that "subtree" packages were
preferred, and "external" packages only recommended for big packages
and maintainers who refused to use the subtree approach.

Since "one branch per package" works mostly (*) like "one repository
per package", I don't think teaching Elpa to pull is a good idea.
The downsides of doing that have already been discussed and as long
as one goes with the "subtree" option, I don't see the need.

*: git remote add -t externals/<package> --no-tags elpa git://...
     vs.
   git remote add elpa git://...

  Cheers,
  Jonas

Re: Adding advisory notification for non-ELPA package.el downloads

[Nicolas Petton]

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

Richard Stallman <rms@gnu.org> writes:

>   > > Who would like to implement these suggested communications in ELPA
>   > > itself?
>
>   > What do you mean by "in ELPA itself"?
>
> Someone proposed making these changes in ELPA, in its web pages, and
> repo.  They would be changes in ELPA itself.
>
> Would someone like to implement them (in ELPA)?

I can add a web page, but I'd need help with the content.

Cheers,
Nico

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

Re: Improving GNU ELPA

[Phillip Lord]

Jonas Bernoulli <jonas@bernoul.li> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>>   git fetch elpa
>>>   git filter-branch
>>
>> That's only for the "subtree" packages.  You can use an "external"
>> package, in which case the package has its own branch.
>>
>>> So I think the focus should be on enabling "one repository per package"
>>
>> One repository per package would be a bit more convenient in some cases,
>> admittedly, but one branch per package is not that bad.
>
> That works for me, and I suspect for many others too.

I have used a branch for my packages so that it (mostly) remains as
simple as git pull/git push.

It does bring some added complexity, as the git pull is a potential
merge. In the case of magit, this is not going to be a problem as you
know how to use git well: you can avoid the merge if you want or deal
with it if you want. For others, it might be a little harder. It is why
I think ELPA should be modified by PRs where an upstream exists. Having
a branch makes this easier also.

Phil

Re: Improving GNU ELPA

[Stefan Monnier]

> I was somehow under the impression that "subtree" packages were
> preferred, and "external" packages only recommended for big packages
> and maintainers who refused to use the subtree approach.

It's up to the package's maintainer to decide.


        Stefan

Re: Improving GNU 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 was somehow under the impression that "subtree" packages were
  > > preferred, and "external" packages only recommended for big packages
  > > and maintainers who refused to use the subtree approach.

  > It's up to the package's maintainer to decide.

People have presented complicated workflows, saying those are required
to install any patch in ELPA, and that this makes using ELPA a pain.
Those did seem so complicated that it would be a pain in the neck to
do this.

Are those complicated workflows for "subtree" packages only?
Does using an "external" package avoid the problem?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Improving GNU ELPA

[Stefan Monnier]

> Are those complicated workflows for "subtree" packages only?

Yes (and only if you use a separate upstream).

> Does using an "external" package avoid the problem?

Yes,


        Stefan

Re: Improving GNU ELPA

[Phillip Lord]

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

>> Are those complicated workflows for "subtree" packages only?
>
> Yes (and only if you use a separate upstream).
>
>> Does using an "external" package avoid the problem?
>
> Yes,


Mostly.

With dash, I can push to elpa, but not to upstream. So, changes occuring
to dash on ELPA, have to be pulled onto a branch, turned into a PR for
dash.

If I could push to upstream, it would be simpler, but still require
merges.

Phil

Re: Improving GNU ELPA

[Stefan Monnier]

> If I could push to upstream, it would be simpler, but still require
> merges.

AFAIU, what you mean by "merges" is simply the result of changes being
made both to the github repository and to the elpa.git repository.
It's unrelated to how the copy of dash kept on the gnu.org side is
stored (a subtree, or a separate branchm or a separate repository) as
long as it can be modified on the gnu.org side.

Right?


        Stefan

Re: Improving GNU 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. ]]]

  > > Are those complicated workflows for "subtree" packages only?

  > Yes (and only if you use a separate upstream).

Using a separate upstream can be ok, if we ensure proper rules are
followed, to avoid difficulties.

What are the current rules for using a separate upstream
in ELPA?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Improving GNU 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. ]]]

  > With dash, I can push to elpa, but not to upstream. So, changes occuring
  > to dash on ELPA, have to be pulled onto a branch, turned into a PR for
  > dash.

The reason I say we should have admin access to the real repository
is to avoid problem situations like this one.



-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Improving GNU ELPA

[Stefan Monnier]

> What are the current rules for using a separate upstream
> in ELPA?

There are no real rules, here, other than the fact that elpa.git may be
modified by us directly, so if the maintainer decides to keep the
"upstream" elsewhere it's his responsibility to deal with the fallout

[ We try to help with that by automatically sending her an email with
  the diffs that have been installed, tho this automatic forwarding is
  currently broken, as mentioned earlier in this thread:

  > - when someone commits to elpa.git we get an elpa-diffs email which
  >   I used to then forward to the corresponding package maintainer.
  >   This forwarding is currently broken because of changes to my
  >   email server.  This should really be done in elpa.gnu.org instead of
  >   iro.umontreal.ca anyway, so I don't intend to fix the old setup.

  Help would be very warmly welcome here.  ]

More generally: it's not ideas that are missing, it's people helping
improve the setup.


        Stefan

Re: Improving GNU ELPA

[Phillip Lord]

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

>> If I could push to upstream, it would be simpler, but still require
>> merges.
>
> AFAIU, what you mean by "merges" is simply the result of changes being
> made both to the github repository and to the elpa.git repository.
> It's unrelated to how the copy of dash kept on the gnu.org side is
> stored (a subtree, or a separate branchm or a separate repository) as
> long as it can be modified on the gnu.org side.
>
> Right?

I think so, yes. I've never used subtrees. Orphan branches in a repo are
essentially the same as a separate repo except that they share a
namespace for branches and tags. So, I guess, with a separate repo you
could do things like make a feature branch and then PR for this
upstream.

But in terms of use, not modifying the gnu.org side (except in
exceptional circumstances) would make the use of ELPA with an upstream
repo easier. ELPA would, effectively, operate like Jonas' emacsmirror;
there in case the upstream disappeared.

Phil

Re: Improving GNU ELPA

[Phillip Lord]

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

>> What are the current rules for using a separate upstream
>> in ELPA?
>
> There are no real rules, here, other than the fact that elpa.git may be
> modified by us directly, so if the maintainer decides to keep the
> "upstream" elsewhere it's his responsibility to deal with the fallout

This bit I don't like!

> [ We try to help with that by automatically sending her an email with
>   the diffs that have been installed, tho this automatic forwarding is
>   currently broken, as mentioned earlier in this thread:
>
>   > - when someone commits to elpa.git we get an elpa-diffs email which
>   >   I used to then forward to the corresponding package maintainer.
>   >   This forwarding is currently broken because of changes to my
>   >   email server.  This should really be done in elpa.gnu.org instead of
>   >   iro.umontreal.ca anyway, so I don't intend to fix the old setup.
>
>   Help would be very warmly welcome here.  ]
>
> More generally: it's not ideas that are missing, it's people helping
> improve the setup.


What sort of commits do you do locally? Would scripting something to
branch, and do git-request-pull to the upstream be a substitute?

Phil

Re: Improving GNU ELPA

[Phillip Lord]

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. ]]]
>
>   > With dash, I can push to elpa, but not to upstream. So, changes occuring
>   > to dash on ELPA, have to be pulled onto a branch, turned into a PR for
>   > dash.
>
> The reason I say we should have admin access to the real repository
> is to avoid problem situations like this one.

As I said, it doesn't avoid the problem, it just changes the nature of
that problem. As Stefan has said, at the moment, dealing with these
issues is, anyway, consider the problem of the upstream person. The
presence of push rights changes nothing if you do not use them.

Phil

Re: Improving GNU ELPA

[Stefan Monnier]

>> There are no real rules, here, other than the fact that elpa.git may be
>> modified by us directly, so if the maintainer decides to keep the
>> "upstream" elsewhere it's his responsibility to deal with the fallout
> This bit I don't like!

You're not alone, so in general we should try to avoid it.

> What sort of commits do you do locally?

Not sure what you mean by "locally".  Do you mean, what kinds of commits
do we want to install directly into elpa.git (for those cases where the
upstream is elsewhere)?

Typically things like incorrect copyright notices or compilation breakage.

> Would scripting something to branch, and do git-request-pull to the
> upstream be a substitute?

Nowadays, most of time I send a patch via email to the maintainer rather
than committing directly.  It's more tedious but since I now do much less
janitorial work on elpa.git code it's OK.


        Stefan

Re: Improving GNU 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. ]]]

  > As I said, it doesn't avoid the problem, it just changes the nature of
  > that problem.

I have a hunch that "the problem" you are talking about is not the
same problem.  I can't verify this, because you tallk about "the
problem" tersely in the abstract, without stating concretely what
problem you mean.  But I am pretty sure it's not the one I am trying
to avoid.

		  As Stefan has said, at the moment, dealing with these
  > issues is, anyway, consider the problem of the upstream person.

I would describe that as the "easy way out".  You consider it a good
option and recommend it as a solution, but I see it as opening a can
of worms.  Thus, for me it is "the problem" and I am looking for how
we can _avoid_ it.

  > The
  > presence of push rights changes nothing if you do not use them.

Alas, I don't follow -- that is rather terse, so I don't understand
the point.  I am not sure whether I would agree or disagree, if I
understood.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Improving GNU ELPA

[Phillip Lord]

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. ]]]
>
>   > As I said, it doesn't avoid the problem, it just changes the nature of
>   > that problem.
>
> I have a hunch that "the problem" you are talking about is not the
> same problem.  I can't verify this, because you tallk about "the
> problem" tersely in the abstract, without stating concretely what
> problem you mean.  But I am pretty sure it's not the one I am trying
> to avoid.

Specifically, that I cannot push to dash on github which is the main
repository. This is not a big deal, I just haven't asked for it.

>
> 		  As Stefan has said, at the moment, dealing with these
>   > issues is, anyway, consider the problem of the upstream person.
>
> I would describe that as the "easy way out".  You consider it a good
> option and recommend it as a solution, but I see it as opening a can
> of worms.  Thus, for me it is "the problem" and I am looking for how
> we can _avoid_ it.
>
>   > The
>   > presence of push rights changes nothing if you do not use them.
>
> Alas, I don't follow -- that is rather terse, so I don't understand
> the point.  I am not sure whether I would agree or disagree, if I
> understood.


So, the issue is this:

Assume we have a package (like dash) which is maintained and developed
in some external git repo.

I think, ELPA would be easier to use if it just pulled directly and
automatically from this external git repo. If the Emacs maintainers want
to update that package, they should use PRs to the upstream. Commit or
push rights on upstream are not necessary. This is enough, for most
cases, and is also easy for the upstream developer. This is also how
MELPA runs, so clearly it can work in practice.

There are emergencies that we might concieve of where a change needs to
be made to ELPA immediately, today, without any delay. In these
circumstances, a copy of the project history would be available in the
ELPA repository. Changes could be made there, with the knowledge that
the upstream package would need to do something to reincorporate these
emergency changes. MELPA has a similar policy for switching upstream.

This requires almost no software (just something to run the pull), no
changes to ELPA, just a change in policy. In response, ELPA becomes a
little more frictionless, a little more convienient for contributors.

Going round in circles here, so I stop.

Phil

Re: Improving GNU ELPA

[Phillip Lord]

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

>>> There are no real rules, here, other than the fact that elpa.git may be
>>> modified by us directly, so if the maintainer decides to keep the
>>> "upstream" elsewhere it's his responsibility to deal with the fallout
>> This bit I don't like!
>
> You're not alone, so in general we should try to avoid it.
>
>> What sort of commits do you do locally?
>
> Not sure what you mean by "locally".  Do you mean, what kinds of commits
> do we want to install directly into elpa.git (for those cases where the
> upstream is elsewhere)?

Yes, precisely so.

> Typically things like incorrect copyright notices or compilation breakage.

Does ELPA not check for the copyright? I.e. if it's incorrect, it will
be wrong in the git repo only and not in the distributed ELPA package.


>> Would scripting something to branch, and do git-request-pull to the
>> upstream be a substitute?
>
> Nowadays, most of time I send a patch via email to the maintainer rather
> than committing directly.  It's more tedious but since I now do much less
> janitorial work on elpa.git code it's OK.

janitorial work is always tedious!

Phil

Re: Adding advisory notification for non-ELPA package.el downloads

[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 can add a web page, but I'd need help with the content.

Would anyone like to help Nicolas implement the ELPA documentation
and guidance suggestions?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Improving GNU 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. ]]]

  > > Typically things like incorrect copyright notices or compilation breakage.

  > Does ELPA not check for the copyright? I.e. if it's incorrect, it will
  > be wrong in the git repo only and not in the distributed ELPA package.

We could make ELPA check that files have the correct copyright notices.
We could also make it check that they have the correct license notices.
It would be useful to implement sending us warnings for that.

Would anyone like to implement this?

However, the crucial thing is not what the file SAYS about copyright,
but what the actual facts are about the copyright.  We take care of
that by getting copyright assignments.  Once that is done, if a notice
in a file is inaccurate, all we need to do is correct it.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Improving GNU ELPA

[Phillip Lord]

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. ]]]
>
>   > > Typically things like incorrect copyright notices or compilation breakage.
>
>   > Does ELPA not check for the copyright? I.e. if it's incorrect, it will
>   > be wrong in the git repo only and not in the distributed ELPA package.
>
> We could make ELPA check that files have the correct copyright notices.
> We could also make it check that they have the correct license notices.
> It would be useful to implement sending us warnings for that.
>
> Would anyone like to implement this?

It already does this.

Incorrect copyright notices are nothing urgent, since they need not go
live to elpa.gnu.org -- they will be present only in git. So not an
urgent need for changes.

Phil