Adding advisory notification for non-ELPA package.el downloads

classic Classic list List threaded Threaded
89 messages Options
12345
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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 [hidden email]
    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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Kaushal Modi
On Sat, Jul 8, 2017, 6:29 AM Dmitry Gutov <[hidden email]> 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 [hidden email] 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 [hidden email] 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Clément Pit-Claudel
In reply to this post by John Wiegley
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.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Richard Stallman
In reply to this post by Dmitry Gutov
[[[ 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.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Jean-Christophe Helary

On Jul 9, 2017, at 2:03, Richard Stallman <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Tim Cross-5
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 <[hidden email]> wrote:

On Jul 9, 2017, at 2:03, Richard Stallman <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Dmitry Gutov
In reply to this post by Richard Stallman
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.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Yann Hodique
In reply to this post by Clément Pit-Claudel
>>>>> "Clément" == Clément Pit-Claudel <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Chad Brown
In reply to this post by Dmitry Gutov

> On 8Jul, 2017, at 17:39, Dmitry Gutov <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Richard Stallman
In reply to this post by Dmitry Gutov
[[[ 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.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Richard Stallman
In reply to this post by Jean-Christophe Helary
[[[ 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.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Richard Stallman
In reply to this post by Tim Cross-5
[[[ 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.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Richard Stallman
In reply to this post by Yann Hodique
[[[ 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.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Dmitry Gutov
In reply to this post by Richard Stallman
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?

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

ken manheimer
In reply to this post by Richard Stallman
On Mon, Jul 10, 2017 at 5:27 AM, Richard Stallman <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

ken manheimer
In reply to this post by Richard Stallman
On Mon, Jul 10, 2017 at 5:29 AM, Richard Stallman <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Yann Hodique
In reply to this post by Richard Stallman
>>>>> "Richard" == Richard Stallman <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Joost Kremers-2
In reply to this post by Clément Pit-Claudel

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Richard Stallman
In reply to this post by ken manheimer
[[[ 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.


12345
Loading...