Re: "Write a new package" culture instead of patches?

Re: "Write a new package" culture instead of patches?

[ndame]

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

> Has anyone else thought about this?  Is it correct to say that such a
> "package first" culture has developed?  If yes, why has it developed,
> and is there anything we could do about it?

The obvious answer  is because they solved the problem, it works, available to anyone and they can't be bothered with jumping through additional hoops (paperwork, following the core rules for docs, code formatting, commit message, etc.).

For some people getting their code into the core is a source of pride. For others it's a pointless excercise, because it's trivially available from MELPA which the majority of users use anyway for other packages too.

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

Re: "Write a new package" culture instead of patches?

[Eli Zaretskii]

> Date: Sun, 17 May 2020 19:25:50 +0000
> From: ndame <ndame@protonmail.com>
> 
> The obvious answer  is because they solved the problem, it works, available to anyone and they can't be
> bothered with jumping through additional hoops (paperwork, following the core rules for docs, code
> formatting, commit message, etc.).
> 
> For some people getting their code into the core is a source of pride. For others it's a pointless excercise,
> because it's trivially available from MELPA which the majority of users use anyway for other packages too.

But MELPA asks you to jump through a different set of hoops, which
seems to fly in the face of your theory.

IME, many people who "solved the problem" want others to enjoy their
solution, and that is what gives them the incentive to "jump through
hoops".

Re: "Write a new package" culture instead of patches?

[ndame]

>
> But MELPA asks you to jump through a different set of hoops, which
> seems to fly in the face of your theory.

You mean setting up MELPA access? Users do that anyway, because many great packages are only available there, so that hoop has to be jumped regardless.


> IME, many people who "solved the problem" want others to enjoy their
> solution, and that is what gives them the incentive to "jump through
> hoops".

Sure. But the question was about those people who don't do that.

And in the latter case others can still enjoy the solution easily via MELPA. Those users who don't set up MELPA are a minority.

So Emacs/ELPA should provide a good use case which MELPA can't provide. The only thing I know is if there is no internet connection then packages are available locally, but I don't know how typical that is.

Re: "Write a new package" culture instead of patches?

[Eli Zaretskii]

> Date: Sun, 17 May 2020 19:43:54 +0000
> From: ndame <ndame@protonmail.com>
> Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> >
> > But MELPA asks you to jump through a different set of hoops, which
> > seems to fly in the face of your theory.
> 
> You mean setting up MELPA access?

No, I mean the MELPA contribution requirements.  I'm talking about
those who provide packages, not those who use them.  Using packages
from ELPA doesn't require any jumps.

> So Emacs/ELPA should provide a good use case which MELPA can't provide. The only thing I know is if there is no internet connection then packages are available locally, but I don't know how typical that is.

No, the use case is that ELPA has higher quality code that never
promotes or uses proprietary software.

Re: "Write a new package" culture instead of patches?

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sun, 17 May 2020 19:25:50 +0000
>> From: ndame <ndame@protonmail.com>
>> 
>> The obvious answer  is because they solved the problem, it works, available to anyone and they can't be
>> bothered with jumping through additional hoops (paperwork, following the core rules for docs, code
>> formatting, commit message, etc.).
>> 
>> For some people getting their code into the core is a source of pride. For others it's a pointless excercise,
>> because it's trivially available from MELPA which the majority of users use anyway for other packages too.
>
> But MELPA asks you to jump through a different set of hoops, which
> seems to fly in the face of your theory.
>
> IME, many people who "solved the problem" want others to enjoy their
> solution, and that is what gives them the incentive to "jump through
> hoops".
To me I just want to save some cpu cycles :-). Somebody could take and
re-write my ls-switch thingy better, and I would be happy as long as I
don't need to download 3rd party package and overwrite already loaded
software everytime I start Emacs (as long as it does what I need). So
patch in Emacs is to prefer to 3rd party package in my eyes. At least
for very common, often used stuff.

Kind-of green-thinking, saving unnecessary wasted cpu cycles saves
energy as well for me as for the nature. Maybe ridicolous thinking, but
why we load so much stuff into Emacs, just to overwrite it on boot time?
:-)

I think efficiency in computing should be in general taken more
seriously, I think it is morally as important as
privacy/freedom/integrity considerations which FSF/GNU people are
standing for.

Re: "Write a new package" culture instead of patches?

[ndame]

>
> But MELPA asks you to jump through a different set of hoops, which
> seems to fly in the face of your theory.

Oh, you mean hoops for getting into MELPA. I don't what those are, but I assume there are less hoops there.

Re: "Write a new package" culture instead of patches?

[Philippe Vaucher]

> > But MELPA asks you to jump through a different set of hoops, which
> > seems to fly in the face of your theory.
>
> Oh, you mean hoops for getting into MELPA. I don't what those are, but I assume there are less hoops there.

Back in the days it was just Purcell reviewing and letting some things
fly, but nowadays you have to follow
https://github.com/melpa/melpa/blob/master/CONTRIBUTING.org#making-your-package-ready-for-inclusion

That is, before inclusion they semi-automated that checkdoc is happy,
that the whole package is prefixed, that the names style is not
"anti-emacs", etc.

That said, for those living on github/gitlab/etc compared to ELPA you
feel at home... you just open issues, make pull requests & get
answered there, you feel "welcome". On ELPA/emacs-devel you don't feel
as welcome because of copyright assignments / subscribing to a mailing
list / having to create patches and send an email, that plus usually
the first answer you receive is that you did your commit message all
wrong and that it follows complex rules in a tone that is more serious
and "hard work" than what you get on MELPA.

Hope it helps,
Philippe

Re: "Write a new package" culture instead of patches?

[Eli Zaretskii]

> From: Philippe Vaucher <philippe.vaucher@gmail.com>
> Date: Mon, 18 May 2020 07:41:42 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> That said, for those living on github/gitlab/etc compared to ELPA you
> feel at home... you just open issues, make pull requests & get
> answered there, you feel "welcome". On ELPA/emacs-devel you don't feel
> as welcome because of copyright assignments / subscribing to a mailing
> list / having to create patches and send an email, that plus usually
> the first answer you receive is that you did your commit message all
> wrong and that it follows complex rules in a tone that is more serious
> and "hard work" than what you get on MELPA.

I think you make the MELPA rules sound easier, and our rules sound
harder, than they actually are.  I suggest to scan the archives for
proposals to add new packages to ELPA, where you will see neither the
need to subscribe to this list, nor the need to create patches and
email them, nor "all wrong" responses with a certain "tone".  At least
not in general.

Re: "Write a new package" culture instead of patches?

[Yoni Rabkin]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philippe Vaucher <philippe.vaucher@gmail.com>
>> Date: Mon, 18 May 2020 07:41:42 +0200
>> Cc: Eli Zaretskii <eliz@gnu.org>, "emacs-devel@gnu.org" <emacs-devel@gnu.org>
>> 
>> That said, for those living on github/gitlab/etc compared to ELPA you
>> feel at home... you just open issues, make pull requests & get
>> answered there, you feel "welcome". On ELPA/emacs-devel you don't feel
>> as welcome because of copyright assignments / subscribing to a mailing
>> list / having to create patches and send an email, that plus usually
>> the first answer you receive is that you did your commit message all
>> wrong and that it follows complex rules in a tone that is more serious
>> and "hard work" than what you get on MELPA.
>
> I think you make the MELPA rules sound easier, and our rules sound
> harder, than they actually are.  I suggest to scan the archives for
> proposals to add new packages to ELPA, where you will see neither the
> need to subscribe to this list, nor the need to create patches and
> email them, nor "all wrong" responses with a certain "tone".  At least
> not in general.

Rules can be a good thing.

I'm the maintainer of GNU/Emms (a media player for Emacs). The people
who distribute Emms on MELPA do a poor job of it (see below), and have
never communicated with us, the Emms developers about it (not even
once). I only discovered about it by chance recently when I went out to
figure out what M/ELPA is, and how I can add Emms to ELPA.

What the MEPLA people are doing that I don't like:

    * Never communicate with the developers of the Emms in any way.

    * Omit many files that come with Emms.

    * Associate Emms with several Emms extensions that live only on
      MELPA and that we, the Emms developers, have never heard
      about. This would give anyone accessing Emms via MELPA that those
      extensions are somehow a part of Emms, when they are not.

      Maybe those extensions are good, in which case I would love for
      the developers to contact us, the Emms developers. But Maybe those
      extensions are bad, don't work, are out of date, or connect with
      non-free services.

    * Not even linking to the Emms home page
      (https://www.gnu.org/software/emms/).

Thought and effort goes into packaging each version Emms, and presenting
Emms in the best way. It is a shame to see it ignored by this
distribution system.

Ideas for improvement:

    * Encourage people to speak to the developers of a project before
      packaging it.

    * Find a way of packaging a project as-is. For instance, Emms could
      be distributed as is, and the M/ELPA software could simply point
      at where Emms keeps its .el files for Emacs to find. This is
      instead of how I see ELPA working now, which is to force the
      software through a kind of a sieve (I think ELPA calls it a
      recipe) where only a select few files come out the other end.

      Emms doesn't need a recipe; it already comes organized and
      packaged for working with Emacs.

      It makes me think of taking bread, crumbling it up, the mushing
      those crumbs back together to re-form a new loaf of bread.

-- 
   "Cut your own wood and it will warm you twice"

Re: "Write a new package" culture instead of patches?

[Clément Pit-Claudel]

On 18/05/2020 11.22, Yoni Rabkin wrote:
> I'm the maintainer of GNU/Emms (a media player for Emacs). The people
> who distribute Emms on MELPA do a poor job of it (see below), and have
> never communicated with us, the Emms developers about it (not even
> once). I only discovered about it by chance recently when I went out to
> figure out what M/ELPA is, and how I can add Emms to ELPA.
> 
> What the MEPLA people are doing that I don't like:

I think you're a bit harsh with the MELPA folks. EMMS was added to MELPA eight years ago, back when it was just getting started, so I wouldn't judge based on that.  See below re. contacting package authors.

>     * Associate Emms with several Emms extensions that live only on
>       MELPA and that we, the Emms developers, have never heard
>       about. This would give anyone accessing Emms via MELPA that those
>       extensions are somehow a part of Emms, when they are not.

What do you mean by this?  MELPA is the same as ELPA in this regard: anyone can publish an "emms-xyz" package, right?

>     * Not even linking to the Emms home page
>       (https://www.gnu.org/software/emms/).

I think it does: I see this when I open the package in M-x list-packages:

   Homepage: https://www.gnu.org/software/emms/

The MELPA website links to the git repository instead.

> Ideas for improvement:
> 
>     * Encourage people to speak to the developers of a project before
>       packaging it.

The current guidelines say the following:

Contact package author
    If you are not the original author or maintainer of the package you are submitting, please notify the authors prior to submitting and include them in the pull request process.

… so things have indeed improved a lot since 2012.

>     * Find a way of packaging a project as-is. For instance, Emms could
>       be distributed as is, and the M/ELPA software could simply point
>       at where Emms keeps its .el files for Emacs to find. This is
>       instead of how I see ELPA working now, which is to force the
>       software through a kind of a sieve (I think ELPA calls it a
>       recipe) where only a select few files come out the other end.

It's trivial to make a recipe that includes all files, so I wouldn't worry about this.

>       Emms doesn't need a recipe; it already comes organized and
>       packaged for working with Emacs.

I think most users these days expect "packaged" to mean "installable using package.el", while EMMS only provides source releases; that's why you see the MELPA recipe slicing and dicing the emms repo.

It will be great to have an improved EMMS recipe in MELPA!  If you run into trouble, you should ask on the bug tracker; the MELPA folks are great.

Cheers,
Clément.

Re: "Write a new package" culture instead of patches?

[Yoni Rabkin]

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

> On 18/05/2020 11.22, Yoni Rabkin wrote:
>> I'm the maintainer of GNU/Emms (a media player for Emacs). The people
>> who distribute Emms on MELPA do a poor job of it (see below), and have
>> never communicated with us, the Emms developers about it (not even
>> once). I only discovered about it by chance recently when I went out to
>> figure out what M/ELPA is, and how I can add Emms to ELPA.
>> 
>> What the MEPLA people are doing that I don't like:
>
> I think you're a bit harsh with the MELPA folks. EMMS was added to
> MELPA eight years ago, back when it was just getting started, so I
> wouldn't judge based on that.  See below re. contacting package
> authors.

I apologize for being harsh. I shouldn't have done that.

I re-read what I've written below to see if it is harsh. It is
opinionated, I don't think it is harsh. If it is harsh, please don't
hesitate to point it out. I'll be happy for pointers on how to make my
writing more kind.

>>     * Associate Emms with several Emms extensions that live only on
>>       MELPA and that we, the Emms developers, have never heard
>>       about. This would give anyone accessing Emms via MELPA that those
>>       extensions are somehow a part of Emms, when they are not.
>
> What do you mean by this?  MELPA is the same as ELPA in this regard:
> anyone can publish an "emms-xyz" package, right?

The site, https://melpa.org/#/emms, lists a number of projects under
"needed by". But there is no differentiation between Emms, a GNU
project, and those "needed by" projects.

I agree that it is their right to distribute Emms as they wish as long
as they abide by the terms of the license, but I do not agree that their
particular form of distribution is good for Emms (no quality control for
those "needed by" projects; do they even work?) or if it is good for the
people who enjoy Emms (maybe they steer people to use proprietary
services.)

The word "gnu" doesn't even appear on the website for Emms on
MELPA. Surely there is some value to pointing out to people which part
of what is being distributed is a GNU project, and thereby subject to
GNU's standards. People can then go on to ignore the information, but at
least they have access to it.


>>     * Not even linking to the Emms home page
>>       (https://www.gnu.org/software/emms/).
>
> I think it does: I see this when I open the package in M-x list-packages:
>
>    Homepage: https://www.gnu.org/software/emms/
>
> The MELPA website links to the git repository instead.

Yes, that was what I was referring to.

>> Ideas for improvement:
>> 
>>     * Encourage people to speak to the developers of a project before
>>       packaging it.
>
> The current guidelines say the following:
>
> Contact package author
>     If you are not the original author or maintainer of the package
>     you are submitting, please notify the authors prior to submitting
>     and include them in the pull request process.
>
> … so things have indeed improved a lot since 2012.

Not in the case of Emms, since nobody has done so. Therefore, Emms has
not been the beneficiary of such an improvement.

>>     * Find a way of packaging a project as-is. For instance, Emms could
>>       be distributed as is, and the M/ELPA software could simply point
>>       at where Emms keeps its .el files for Emacs to find. This is
>>       instead of how I see ELPA working now, which is to force the
>>       software through a kind of a sieve (I think ELPA calls it a
>>       recipe) where only a select few files come out the other end.
>
> It's trivial to make a recipe that includes all files, so I wouldn't
> worry about this.

The Emms distribution already contains all of the files by defintion;
none needed to be remove to begin with. I feel like we looking at the
issue from two different viewpoints.

>>       Emms doesn't need a recipe; it already comes organized and
>>       packaged for working with Emacs.
>
> I think most users these days expect "packaged" to mean "installable
> using package.el", while EMMS only provides source releases; that's
> why you see the MELPA recipe slicing and dicing the emms repo.

I don't agree with "most people"-type statements as an argument for a
number of reasons, among them that I've always been against speaking on
behalf of other people. I can speak for myself as the maintainer of Emms
on behalf of GNU, and try to steer toward to the goal of the GNU project
when doing so. I don't check to see if there is a majority or minority
supporting me in this regard.


> It will be great to have an improved EMMS recipe in MELPA!  If you run
> into trouble, you should ask on the bug tracker; the MELPA folks are
> great.

Why does Emms need to be offered through three different channels at the
same time?

Ideally, I would contact the MELPA bug tracker and have Emms removed
from MELPA, since it can be trivially downloaded from a GNU server, and
will hopefully soon be installable via ELPA.

However, since nobody asked last time they installed Emms there, nothing
would stop them from installing it on MELPA again, or modifying the
recipe to exclude files again. Since MELPA offers the Emms project no
control over distribution, I don't have much incentive to work on how
Emms is distributed there, or to fix it and then schedule a weekly
excursion to MELPA to see if someone has broken it.

Please forgive me if I'm misunderstanding something fundamental about
how MELPA works. As I've mentioned before, I don't use it or ELPA.

-- 
   "Cut your own wood and it will warm you twice"

Re: "Write a new package" culture instead of patches?

[Dmitry Gutov]

On 18.05.2020 20:30, Yoni Rabkin wrote:

>>>      * Associate Emms with several Emms extensions that live only on
>>>        MELPA and that we, the Emms developers, have never heard
>>>        about. This would give anyone accessing Emms via MELPA that those
>>>        extensions are somehow a part of Emms, when they are not.
>>
>> What do you mean by this?  MELPA is the same as ELPA in this regard:
>> anyone can publish an "emms-xyz" package, right?
> 
> The site, https://melpa.org/#/emms, lists a number of projects under
> "needed by". But there is no differentiation between Emms, a GNU
> project, and those "needed by" projects.
> 
> I agree that it is their right to distribute Emms as they wish as long
> as they abide by the terms of the license, but I do not agree that their
> particular form of distribution is good for Emms (no quality control for
> those "needed by" projects; do they even work?) or if it is good for the
> people who enjoy Emms (maybe they steer people to use proprietary
> services.)

People just learn to understand that different packages usually means 
different authors, and having the prefix emms- on many packages has 
little bearing on your reputation.

> The word "gnu" doesn't even appear on the website for Emms on
> MELPA. Surely there is some value to pointing out to people which part
> of what is being distributed is a GNU project, and thereby subject to
> GNU's standards. People can then go on to ignore the information, but at
> least they have access to it.

That is because the main package file doesn't follow the ELPA standard 
of having it commentary describe the whole package.

See the "Description" on the MELPA site. The area can host a more 
thorough description if you make it so.

>>>      * Not even linking to the Emms home page
>>>        (https://www.gnu.org/software/emms/).
>>
>> I think it does: I see this when I open the package in M-x list-packages:
>>
>>     Homepage: https://www.gnu.org/software/emms/
>>
>> The MELPA website links to the git repository instead.
> 
> Yes, that was what I was referring to.

And that is because, I'm guessing, your main package file doesn't have 
the "Homepage" header.

>> The current guidelines say the following:
>>
>> Contact package author
>>      If you are not the original author or maintainer of the package
>>      you are submitting, please notify the authors prior to submitting
>>      and include them in the pull request process.
>>
>> … so things have indeed improved a lot since 2012.
> 
> Not in the case of Emms, since nobody has done so. Therefore, Emms has
> not been the beneficiary of such an improvement.

The above are guidelines for when a package recipe is submitted. Once 
it's submitted, the package simply continues to be distributed. Unless 
someone raises an issue, proposes a better recipe, etc.

>>>      * Find a way of packaging a project as-is. For instance, Emms could
>>>        be distributed as is, and the M/ELPA software could simply point
>>>        at where Emms keeps its .el files for Emacs to find. This is
>>>        instead of how I see ELPA working now, which is to force the
>>>        software through a kind of a sieve (I think ELPA calls it a
>>>        recipe) where only a select few files come out the other end.
>>
>> It's trivial to make a recipe that includes all files, so I wouldn't
>> worry about this.
> 
> The Emms distribution already contains all of the files by defintion;
> none needed to be remove to begin with. I feel like we looking at the
> issue from two different viewpoints.

Yes: MELPA uses "recipes" (files with data in particular format) to 
automate distribution.

>>>        Emms doesn't need a recipe; it already comes organized and
>>>        packaged for working with Emacs.
>>
>> I think most users these days expect "packaged" to mean "installable
>> using package.el", while EMMS only provides source releases; that's
>> why you see the MELPA recipe slicing and dicing the emms repo.
> 
> I don't agree with "most people"-type statements as an argument for a
> number of reasons, among them that I've always been against speaking on
> behalf of other people. I can speak for myself as the maintainer of Emms
> on behalf of GNU, and try to steer toward to the goal of the GNU project
> when doing so. I don't check to see if there is a majority or minority
> supporting me in this regard.

Surely you care about the users' convenience at least a little?

>> It will be great to have an improved EMMS recipe in MELPA!  If you run
>> into trouble, you should ask on the bug tracker; the MELPA folks are
>> great.
> 
> Why does Emms need to be offered through three different channels at the
> same time?

I don't know, really. You could keep the most popular one.

Do you have any download stats for the last year? Or since 2012?

> Ideally, I would contact the MELPA bug tracker and have Emms removed
> from MELPA, since it can be trivially downloaded from a GNU server, and
> will hopefully soon be installable via ELPA.

I'm fairly sure that if you demand to be removed, they will do so.

Doing that would punish existing users, however. So I can hardly 
understand the reasons for doing so.

Re: "Write a new package" culture instead of patches?

[Clément Pit-Claudel]

On 18/05/2020 13.50, Dmitry Gutov wrote:
>>> I think it does: I see this when I open the package in M-x list-packages:
>>>
>>>     Homepage: https://www.gnu.org/software/emms/
>>>
>>> The MELPA website links to the git repository instead.
>>
>> Yes, that was what I was referring to.
> 
> And that is because, I'm guessing, your main package file doesn't have the "Homepage" header.

No, MELPA just doesn't show the homepage.  Just opened a ticket about it: https://github.com/melpa/melpa/issues/6914

Re: "Write a new package" culture instead of patches?

[Dmitry Gutov]

On 18.05.2020 22:17, Clément Pit-Claudel wrote:
> No, MELPA just doesn't show the homepage.  Just opened a ticket about it:https://github.com/melpa/melpa/issues/6914

Thank you for the correction.

Re: "Write a new package" culture instead of patches?

[Yoni Rabkin]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 18.05.2020 20:30, Yoni Rabkin wrote:
>
>>>>      * Associate Emms with several Emms extensions that live only on
>>>>        MELPA and that we, the Emms developers, have never heard
>>>>        about. This would give anyone accessing Emms via MELPA that those
>>>>        extensions are somehow a part of Emms, when they are not.
>>>
>>> What do you mean by this?  MELPA is the same as ELPA in this regard:
>>> anyone can publish an "emms-xyz" package, right?
>> The site, https://melpa.org/#/emms, lists a number of projects under
>> "needed by". But there is no differentiation between Emms, a GNU
>> project, and those "needed by" projects.
>> I agree that it is their right to distribute Emms as they wish as
>> long
>> as they abide by the terms of the license, but I do not agree that their
>> particular form of distribution is good for Emms (no quality control for
>> those "needed by" projects; do they even work?) or if it is good for the
>> people who enjoy Emms (maybe they steer people to use proprietary
>> services.)
>
> People just learn to understand that different packages usually means
> different authors, and having the prefix emms- on many packages has 
> little bearing on your reputation.
>
>> The word "gnu" doesn't even appear on the website for Emms on
>> MELPA. Surely there is some value to pointing out to people which part
>> of what is being distributed is a GNU project, and thereby subject to
>> GNU's standards. People can then go on to ignore the information, but at
>> least they have access to it.
>
> That is because the main package file doesn't follow the ELPA standard
> of having it commentary describe the whole package.
>
> See the "Description" on the MELPA site. The area can host a more
> thorough description if you make it so.
>
>>>>      * Not even linking to the Emms home page
>>>>        (https://www.gnu.org/software/emms/).
>>>
>>> I think it does: I see this when I open the package in M-x list-packages:
>>>
>>>     Homepage: https://www.gnu.org/software/emms/
>>>
>>> The MELPA website links to the git repository instead.
>> Yes, that was what I was referring to.
>
> And that is because, I'm guessing, your main package file doesn't have
> the "Homepage" header.
>
>>> The current guidelines say the following:
>>>
>>> Contact package author
>>>      If you are not the original author or maintainer of the package
>>>      you are submitting, please notify the authors prior to submitting
>>>      and include them in the pull request process.
>>>
>>> … so things have indeed improved a lot since 2012.
>> Not in the case of Emms, since nobody has done so. Therefore, Emms
>> has
>> not been the beneficiary of such an improvement.
>
> The above are guidelines for when a package recipe is submitted. Once
> it's submitted, the package simply continues to be distributed. Unless 
> someone raises an issue, proposes a better recipe, etc.
>
>>>>      * Find a way of packaging a project as-is. For instance, Emms could
>>>>        be distributed as is, and the M/ELPA software could simply point
>>>>        at where Emms keeps its .el files for Emacs to find. This is
>>>>        instead of how I see ELPA working now, which is to force the
>>>>        software through a kind of a sieve (I think ELPA calls it a
>>>>        recipe) where only a select few files come out the other end.
>>>
>>> It's trivial to make a recipe that includes all files, so I wouldn't
>>> worry about this.
>> The Emms distribution already contains all of the files by
>> defintion;
>> none needed to be remove to begin with. I feel like we looking at the
>> issue from two different viewpoints.
>
> Yes: MELPA uses "recipes" (files with data in particular format) to
> automate distribution.
>
>>>>        Emms doesn't need a recipe; it already comes organized and
>>>>        packaged for working with Emacs.
>>>
>>> I think most users these days expect "packaged" to mean "installable
>>> using package.el", while EMMS only provides source releases; that's
>>> why you see the MELPA recipe slicing and dicing the emms repo.
>> I don't agree with "most people"-type statements as an argument for
>> a
>> number of reasons, among them that I've always been against speaking on
>> behalf of other people. I can speak for myself as the maintainer of Emms
>> on behalf of GNU, and try to steer toward to the goal of the GNU project
>> when doing so. I don't check to see if there is a majority or minority
>> supporting me in this regard.
>
> Surely you care about the users' convenience at least a little?

I think we are talking across each other, because I don't understand
what you are referring to.

>>> It will be great to have an improved EMMS recipe in MELPA!  If you run
>>> into trouble, you should ask on the bug tracker; the MELPA folks are
>>> great.
>> Why does Emms need to be offered through three different channels at
>> the
>> same time?
>
> I don't know, really. You could keep the most popular one.
>
> Do you have any download stats for the last year? Or since 2012?

It is hosted on Savannah, but I'm unsure of why it would matter.

>> Ideally, I would contact the MELPA bug tracker and have Emms removed
>> from MELPA, since it can be trivially downloaded from a GNU server, and
>> will hopefully soon be installable via ELPA.
>
> I'm fairly sure that if you demand to be removed, they will do so.
>
> Doing that would punish existing users, however. So I can hardly
> understand the reasons for doing so.

My understanding of it is that some people (the people who emailed the
Emms mailing list about it) would rather be able to have Emacs' package
system install Emms for them.

I further understood that for that to happen, Emms needs to be available
via ELPA. As far as I know, it is the only repository that is officially
a part of the Emacs project.

Once Emms is available on ELPA, people who want Emacs' package manager
to install it will have it available. At that point it would be very
strange, and confusing, to have an identical copy of Emms separately
maintained via MELPA.

I hope that this isn't a common issue, one in which packages are
duplicated between ELPA and MELPA; that would point to something that is
organizationally broken somewhere.

If there is some technical issue that would stop MELPA users from
getting it from ELPA, then perhaps we could organize a way for the ELPA
maintained copy be mirrored to MELPA. That seems like a kludge, but we
should try to do it if that is the only way not to break people's
installation.

The last resort would be to maintain ELPA and MELPA separately. This is
hardly an ideal situation and one that I hope isn't the standard.

Thank you for all of your patience as I'm learning this.

-- 
   "Cut your own wood and it will warm you twice"

Re: "Write a new package" culture instead of patches?

[Dmitry Gutov]

On 18.05.2020 23:13, Yoni Rabkin wrote:
> If there is some technical issue that would stop MELPA users from
> getting it from ELPA, then perhaps we could organize a way for the ELPA
> maintained copy be mirrored to MELPA. That seems like a kludge, but we
> should try to do it if that is the only way not to break people's
> installation.

MELPA requires very little maintenance.

As a package maintainer, MELPA occasionally comes handy when I fix some 
tricky bug or other, but hesitate to tag a new release version yet, and 
the user is not technical enough to check out a commit or apply a patch.

Provided the fix is in the master branch already, I can ask them to wait 
for MELPA to update (which happens within 6-12 hours) and try out the 
new snapshot version (all MELPA versions are snapshot versions).

If you really don't want this happening, yes, you might as well ask them 
to delist your package.

Re: "Write a new package" culture instead of patches?

[Clément Pit-Claudel]

On 18/05/2020 13.30, Yoni Rabkin wrote:
> I agree that it is their right to distribute Emms as they wish as long
> as they abide by the terms of the license, but I do not agree that their
> particular form of distribution is good for Emms (no quality control for
> those "needed by" projects; do they even work?) or if it is good for the
> people who enjoy Emms (maybe they steer people to use proprietary
> services.)

There is a bit of quality control, at package submission time (things regarding proper API documentation, proper namespacing, etc. — but nothing like tests, indeed).
I think the way they display thing isn't much different from what you get with "apt-cache rdepends" on a Debian system (it's not the same as the `Recommends: mpg321` or `Suggests: mp3info` lines that `apt` shows when I ask it `apt show emms`, for example).

>>>     * Not even linking to the Emms home page
>>>       (https://www.gnu.org/software/emms/).
>>
>> I think it does: I see this when I open the package in M-x list-packages:
>>
>>    Homepage: https://www.gnu.org/software/emms/
>>
>> The MELPA website links to the git repository instead.
> 
> Yes, that was what I was referring to.

Good point; I opened a ticket about this.

>>>     * Find a way of packaging a project as-is. For instance, Emms could
>>>       be distributed as is, and the M/ELPA software could simply point
>>>       at where Emms keeps its .el files for Emacs to find. This is
>>>       instead of how I see ELPA working now, which is to force the
>>>       software through a kind of a sieve (I think ELPA calls it a
>>>       recipe) where only a select few files come out the other end.
>>
>> It's trivial to make a recipe that includes all files, so I wouldn't
>> worry about this.
> 
> The Emms distribution already contains all of the files by defintion;
> none needed to be remove to begin with. I feel like we looking at the
> issue from two different viewpoints.

The package manager that comes by default in Emacs 24+ is able to produce ELC and info files automatically, so packages typically don't ship Makefiles.  Additionally, it makes certain assumptions about archive layout that EMMS' releases currently don't abide by; that's why MELPA has recipes.
Distributing through ELPA would require the same modifications: this is just the way package.el works. 

>> It will be great to have an improved EMMS recipe in MELPA!  If you run
>> into trouble, you should ask on the bug tracker; the MELPA folks are
>> great.
> 
> Why does Emms need to be offered through three different channels at the
> same time?
> 
> Ideally, I would contact the MELPA bug tracker and have Emms removed
> from MELPA, since it can be trivially downloaded from a GNU server

Downloading it from a GNU server is very complicated, compared to installing it through MELPA.

> and will hopefully soon be installable via ELPA.

I hope you can put it in ELPA; that would be even better.

> However, since nobody asked last time they installed Emms there, nothing
> would stop them from installing it on MELPA again, or modifying the
> recipe to exclude files again. Since MELPA offers the Emms project no
> control over distribution, I don't have much incentive to work on how
> Emms is distributed there, or to fix it and then schedule a weekly
> excursion to MELPA to see if someone has broken it.

This is not how it will work: EMMS was one of the earlier packages to be included in there, before there was a policy to keep maintainers in the loop.  Today, it wouldn't be included without asking.

> Please forgive me if I'm misunderstanding something fundamental about
> how MELPA works. As I've mentioned before, I don't use it or ELPA.

No worries. The short summary is that MELPA doesn't take an adversarial approach, so if you ask for your package to be removed, it will be removed.
But please don't, not before putting it on ELPA — it will break many users' configurations, since emms is rather popular there.

Do you keep statistics for your web server?  It would be useful to compare how many people install through MELPA and how many download releases directly.

Re: "Write a new package" culture instead of patches?

[Yoni Rabkin]

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

> On 18/05/2020 13.30, Yoni Rabkin wrote:
>> I agree that it is their right to distribute Emms as they wish as long
>> as they abide by the terms of the license, but I do not agree that their
>> particular form of distribution is good for Emms (no quality control for
>> those "needed by" projects; do they even work?) or if it is good for the
>> people who enjoy Emms (maybe they steer people to use proprietary
>> services.)
>
> There is a bit of quality control, at package submission time (things regarding proper API documentation, proper namespacing, etc. — but nothing like tests, indeed).
> I think the way they display thing isn't much different from what you
> get with "apt-cache rdepends" on a Debian system (it's not the same as
> the `Recommends: mpg321` or `Suggests: mp3info` lines that `apt` shows
> when I ask it `apt show emms`, for example).
>
>>>>     * Not even linking to the Emms home page
>>>>       (https://www.gnu.org/software/emms/).
>>>
>>> I think it does: I see this when I open the package in M-x list-packages:
>>>
>>>    Homepage: https://www.gnu.org/software/emms/
>>>
>>> The MELPA website links to the git repository instead.
>> 
>> Yes, that was what I was referring to.
>
> Good point; I opened a ticket about this.

thank you

>>>>     * Find a way of packaging a project as-is. For instance, Emms could
>>>>       be distributed as is, and the M/ELPA software could simply point
>>>>       at where Emms keeps its .el files for Emacs to find. This is
>>>>       instead of how I see ELPA working now, which is to force the
>>>>       software through a kind of a sieve (I think ELPA calls it a
>>>>       recipe) where only a select few files come out the other end.
>>>
>>> It's trivial to make a recipe that includes all files, so I wouldn't
>>> worry about this.
>> 
>> The Emms distribution already contains all of the files by defintion;
>> none needed to be remove to begin with. I feel like we looking at the
>> issue from two different viewpoints.
>
> The package manager that comes by default in Emacs 24+ is able to
> produce ELC and info files automatically, so packages typically don't
> ship Makefiles.  Additionally, it makes certain assumptions about
> archive layout that EMMS' releases currently don't abide by; that's
> why MELPA has recipes.
> Distributing through ELPA would require the same modifications: this is just the way package.el works. 
>
>>> It will be great to have an improved EMMS recipe in MELPA!  If you run
>>> into trouble, you should ask on the bug tracker; the MELPA folks are
>>> great.
>> 
>> Why does Emms need to be offered through three different channels at the
>> same time?
>> 
>> Ideally, I would contact the MELPA bug tracker and have Emms removed
>> from MELPA, since it can be trivially downloaded from a GNU server
>
> Downloading it from a GNU server is very complicated, compared to
> installing it through MELPA.

I personally disagree, but since people have asked me to make Emms
available via ELPA I'm disregarding my personal opinion on the matter.

>> and will hopefully soon be installable via ELPA.
>
> I hope you can put it in ELPA; that would be even better.

Yes, that is the goal.

>> However, since nobody asked last time they installed Emms there, nothing
>> would stop them from installing it on MELPA again, or modifying the
>> recipe to exclude files again. Since MELPA offers the Emms project no
>> control over distribution, I don't have much incentive to work on how
>> Emms is distributed there, or to fix it and then schedule a weekly
>> excursion to MELPA to see if someone has broken it.
>
> This is not how it will work: EMMS was one of the earlier packages to
> be included in there, before there was a policy to keep maintainers in
> the loop.  Today, it wouldn't be included without asking.
>
>> Please forgive me if I'm misunderstanding something fundamental about
>> how MELPA works. As I've mentioned before, I don't use it or ELPA.
>
> No worries. The short summary is that MELPA doesn't take an
> adversarial approach, so if you ask for your package to be removed, it
> will be removed.  But please don't, not before putting it on ELPA — it
> will break many users' configurations, since emms is rather popular
> there.

Once it is on ELPA, would that make the MELPA version redundant? Are
packages duplicated across ELPA and MELPA? If so, why?

> Do you keep statistics for your web server?  It would be useful to
> compare how many people install through MELPA and how many download
> releases directly.

Emms is hosted on Savannah, and I'm guessing that GNU/Linux distribution
grab copies of the release version from Savannah/GNU servers as well, so
even if we had those numbers, I wouldn't know how to make sense of them.

-- 
   "Cut your own wood and it will warm you twice"

Re: "Write a new package" culture instead of patches?

[Clément Pit-Claudel]

On 18/05/2020 16.17, Yoni Rabkin wrote:
> Once it is on ELPA, would that make the MELPA version redundant? Are
> packages duplicated across ELPA and MELPA? If so, why?

Some are duplicated, others not.  I expect any user who has MELPA to have ELPA as well, so duplication isn't necessary to reach everyone.
One difference is that by default, MELPA builds a package for every push to the master branch of your git repository, while ELPA requires an update to the version field of the package header.

> Once Emms is available on ELPA, people who want Emacs' package manager
> to install it will have it available. At that point it would be very
> strange, and confusing, to have an identical copy of Emms separately
> maintained via MELPA.

It wouldn't matter much, I think; but since MELPA uses commit date as its version numbers, people who use both repos would by default get the newer builds from your git repository.

> If there is some technical issue that would stop MELPA users from
> getting it from ELPA, then perhaps we could organize a way for the ELPA
> maintained copy be mirrored to MELPA. That seems like a kludge, but we
> should try to do it if that is the only way not to break people's
> installation.

Well, publishing to MELPA doesn't really require any maintenance, as evidenced by 8 years and 50k downloads ^^

> Thank you for all of your patience as I'm learning this.

Thanks for your dedication and for developing emms.

Re: "Write a new package" culture instead of patches?

[Clément Pit-Claudel]

On 18/05/2020 16.17, Yoni Rabkin wrote:
>>>>>     * Not even linking to the Emms home page
>>>>>       (https://www.gnu.org/software/emms/).
>>>> I think it does: I see this when I open the package in M-x list-packages:
>>>>
>>>>    Homepage: https://www.gnu.org/software/emms/
>>>>
>>>> The MELPA website links to the git repository instead.
>>> Yes, that was what I was referring to.
>> Good point; I opened a ticket about this.
> thank you

Hi Yoni,

Steve just updated the MELPA scripts to link to each package's homepage in addition to the source repository (see https://github.com/melpa/melpa/issues/6914).  The website will update automatically in a few hours.
Thanks again for pointing the issue out.

Re: "Write a new package" culture instead of patches?

[Stefan Monnier]

>> and will hopefully soon be installable via ELPA.
> I hope you can put it in ELPA; that would be even better.

It's already available via ELPA (since MELPA is an ELPA archive).
But, yes, Yoni is working on adding it to GNU ELPA.


        Stefan

Re: "Write a new package" culture instead of patches?

[Clément Pit-Claudel]

On 18/05/2020 10.49, Eli Zaretskii wrote:
>> From: Philippe Vaucher <philippe.vaucher@gmail.com>
>> Date: Mon, 18 May 2020 07:41:42 +0200
>> Cc: Eli Zaretskii <eliz@gnu.org>, "emacs-devel@gnu.org" <emacs-devel@gnu.org>
>>
>> That said, for those living on github/gitlab/etc compared to ELPA you
>> feel at home... you just open issues, make pull requests & get
>> answered there, you feel "welcome". On ELPA/emacs-devel you don't feel
>> as welcome because of copyright assignments / subscribing to a mailing
>> list / having to create patches and send an email, that plus usually
>> the first answer you receive is that you did your commit message all
>> wrong and that it follows complex rules in a tone that is more serious
>> and "hard work" than what you get on MELPA.
> 
> I think you make the MELPA rules sound easier, and our rules sound
> harder, than they actually are.  I suggest to scan the archives for
> proposals to add new packages to ELPA, where you will see neither the
> need to subscribe to this list, nor the need to create patches and
> email them, nor "all wrong" responses with a certain "tone".  At least
> not in general.

Part of the problem could be perception?  MELPA does an incredible job at explaining the process to get accepted (and indeed they get slightly more than one new package per day). 

To address this, what about (1) adding a prominent link to elpa.gnu.org on www.gnu.org/software/emacs, and (2) on elpa.gnu.org, removing "To contribute a new package refer to the README" and replacing it with a new section titled "Contributing packages"? 

That section would include the part of the README that deals with new packages, and would highlight external branches more prominently, since those are closer to MELPA's way of doing things.

How does pushing to these branches work, btw? Do we have a way on savannah to give a user push access to a single branch? Or do we give savannah access to everyone who submits a package?

Clément.

Re: "Write a new package" culture instead of patches?

[Stefan Kangas]

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

> To address this, what about (1) adding a prominent link to
> elpa.gnu.org on www.gnu.org/software/emacs, and (2) on elpa.gnu.org,
> removing "To contribute a new package refer to the README" and
> replacing it with a new section titled "Contributing packages"?

At least (2) would help I think.

But then again, that's assuming that people even visit elpa.gnu.org in
the first place.  So maybe (1) is a good idea too.

Best regards,
Stefan Kangas

Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs]

[Alfred M. Szmidt]

   > This is just a matter of following the good practises that already
   > exist in Emacs.  It would be a bad idea to start making a mess, and
   > then encouraging this mess to become larger.

   Posited on s.el being a mess, which neither it, nor dash.el is. They are
   both nice APIs that are nice to use.

In isolation these libraries do not create a mess, and it was never
claimed that they are so.  The issue is making them part of
Emacs/ELPA, thus encouraging people to start using non-standard Emacs
Lisp conventions in Emacs.  _That_ would be the mess.

I really urge people to carefully read what people have written to
minimize these type of misunderstandings.

   I did manage to drop a dash.el dependency form one of my libraries and
   replace it with seq.el. That worked because it was close to a drop
   in. But people have already chosen to work with dash, or s, or f, even
   though it means adding a dependency because they are nice.

Would you like to suggest which parts of those libraries are nice in
your opinon so that they could maybe be added to Emacs, following
normal Emacs conventions?

Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs]

[조성빈]

> 2020. 5. 12. 오전 1:42, Alfred M. Szmidt <ams@gnu.org> 작성:
> 
> 
>> 
>> This is just a matter of following the good practises that already
>> exist in Emacs.  It would be a bad idea to start making a mess, and
>> then encouraging this mess to become larger.
> 
>   Posited on s.el being a mess, which neither it, nor dash.el is. They are
>   both nice APIs that are nice to use.
> 
> In isolation these libraries do not create a mess, and it was never
> claimed that they are so.  The issue is making them part of
> Emacs/ELPA, thus encouraging people to start using non-standard Emacs
> Lisp conventions in Emacs.  _That_ would be the mess.
> 
> I really urge people to carefully read what people have written to
> minimize these type of misunderstandings.
> 
>   I did manage to drop a dash.el dependency form one of my libraries and
>   replace it with seq.el. That worked because it was close to a drop
>   in. But people have already chosen to work with dash, or s, or f, even
>   though it means adding a dependency because they are nice.
> 
> Would you like to suggest which parts of those libraries are nice in
> your opinon so that they could maybe be added to Emacs, following
> normal Emacs conventions?

There was a long, long controversial thread about this. (And I think this thread is a branch of it?)

All of this discussion started about having some more string functions and renaming some of them so that people didn’t need to use s.el. 

FWIW, nobody asked to add it in Emacs core. The only request was to add it in ELPA, which looks like everybody has a different idea of what it is. (I thought of it as a blessed package repo, but apparently a lot of people here thinks that it’s an extension to Emacs.)

Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs]

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > FWIW, nobody asked to add it in Emacs core. The only request was
  > to add it in ELPA, which looks like everybody has a different idea
  > of what it is.

I see the distinction, but either way it would cause the same problem.
The problem is a second, incoherent set of string functions.

You can _say_ that they are an extension we can ignore, but that is
not true in practice.  If "most packages use them", then no other
programs would be able to define those names for _anything_
and we would need to document them.  In effect, they would
be a part of the Emacs Lisp programming interface and not under
our control.

We can have those functions in Emacs (core, or GNU ELPA) if they
are in niche in the namespace, with a substantial prefix such
as a well-behaved Lisp library should have.
-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs]

[Stefan Monnier]

>   > FWIW, nobody asked to add it in Emacs core. The only request was
>   > to add it in ELPA, which looks like everybody has a different idea
>   > of what it is.
> I see the distinction, but either way it would cause the same problem.
> The problem is a second, incoherent set of string functions.

But it's a problem we can't solve, because the library is out there are
people use it.  Furthermore it's only hypothetical.
The library's been in wide use for many years already, yet Emacs still
chugs along exactly as before.  Including it into GNU ELPA would make no
difference in this respect.

In any case, at this point I'm not really interested in adding any other
of those packages to GNU ELPA.  I'll just recommend people add MELPA to
their `package-archives` and move on.


        Stefan

Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs]

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

  > But it's a problem we can't solve, because the library is out there are
  > people use it.

That is not our resposibility or our problem.  But if we put s.el into
GNU ELPA, it will be our resposibility and our problem.

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

Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs]

[Stefan Monnier]

>   > But it's a problem we can't solve, because the library is out there are
>   > people use it.
> That is not our resposibility or our problem.  But if we put s.el into
> GNU ELPA, it will be our resposibility and our problem.

We could choose to take it upon ourselves, yes, but adding it to GNU
ELPA does not *impose* this responsability on us any more than it is
already the case.


        Stefan

Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs]

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

  > >   > But it's a problem we can't solve, because the library is out there are
  > >   > people use it.
  > > That is not our resposibility or our problem.  But if we put s.el into
  > > GNU ELPA, it will be our resposibility and our problem.

  > We could choose to take it upon ourselves,

Including a package in GNU ELPA implies we invite people to
report problems with it to us, and expect us to fix them.

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

Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs]

[Stefan Monnier]

> Including a package in GNU ELPA implies we invite people to
> report problems with it to us, and expect us to fix them.

No, that is simply not the case.

When people find a bug in a package, they don't instinctively report it
to the place from where they installed it.

We do *accept* bug reports to GNU ELPA packages in our debbugs instance,
and we occasionally invite people to submit them there, but in my
experience people do not expect us to accept bug reports and even less
to fix those bugs.

Most people (somewhat wrongly) think of GNU ELPA as a *distribution*
site for third party packages, like MELPA.


        Stefan

Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs]

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > We do *accept* bug reports to GNU ELPA packages in our debbugs instance,
  > and we occasionally invite people to submit them there, but in my
  > experience people do not expect us to accept bug reports and even less
  > to fix those bugs.

  > Most people (somewhat wrongly) think of GNU ELPA as a *distribution*
  > site for third party packages, like MELPA.

Maybe that changes things.  If we present ELPA as just a distribution site.

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

Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs]

[Eli Zaretskii]

On May 17, 2020 5:53:51 AM GMT+03:00, 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. ]]]
> 
> > We do *accept* bug reports to GNU ELPA packages in our debbugs
> instance,
>   > and we occasionally invite people to submit them there, but in my
> > experience people do not expect us to accept bug reports and even
> less
>   > to fix those bugs.
> 
> > Most people (somewhat wrongly) think of GNU ELPA as a *distribution*
>   > site for third party packages, like MELPA.
> 
> Maybe that changes things.  If we present ELPA as just a distribution
> site.

If we regard ELPA just as distribution site, we shouldn't decide so lightly to leave important packages on ELPA, we should be tend more to adding them to core.

Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs]

[Dmitry Gutov]

On 17.05.2020 16:01, Eli Zaretskii wrote:
>>> Most people (somewhat wrongly) think of GNU ELPA as a*distribution*
>>    > site for third party packages, like MELPA.
>>
>> Maybe that changes things.  If we present ELPA as just a distribution
>> site.
> If we regard ELPA just as distribution site, we shouldn't decide so lightly to leave important packages on ELPA, we should be tend more to adding them to core.

I would like to point out, as an author of several packages, that in my 
experience having a package in ELPA is _better_ than having it in the core.

The exception to that rule is more or less cases where the package is 
not only added but also enabled by default.

Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs]

[Eli Zaretskii]

On May 17, 2020 4:38:40 PM GMT+03:00, Dmitry Gutov <dgutov@yandex.ru> wrote:
> On 17.05.2020 16:01, Eli Zaretskii wrote:
> >>> Most people (somewhat wrongly) think of GNU ELPA as
> a*distribution*
> >>    > site for third party packages, like MELPA.
> >>
> >> Maybe that changes things.  If we present ELPA as just a
> distribution
> >> site.
> > If we regard ELPA just as distribution site, we shouldn't decide so
> lightly to leave important packages on ELPA, we should be tend more to
> adding them to core.
> 
> I would like to point out, as an author of several packages, that in
> my 
> experience having a package in ELPA is _better_ than having it in the
> core.
> 
> The exception to that rule is more or less cases where the package is 
> not only added but also enabled by default.

I'm saying that maybe we shouldn't agree so easily to put a package on ELPA if the author would like more than just distribution services.

Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs]

[Dmitry Gutov]

On 17.05.2020 17:24, Eli Zaretskii wrote:

> I'm saying that maybe we shouldn't agree so easily to put a package on ELPA if the author would like more than just distribution services.

I'd say it all depends. We probably aren't going to simply follow what 
the author will be asking for, either.

Do they want code review? We could do it once (couldn't we?), but if the 
author wants all the changes reviewed all the time, we would probably do 
that only for most important packages. Ones that will be enabled for 
default, maybe?

On the other hand, I don't see why we couldn't do code reviews on ELPA 
for select packages, if the authors ask for it. I don't see that 
happening a lot anyway.

Do they simply ask to be included? Perhaps we should ask why. Up until 
now, we often pointed at GNU ELPA and proposed that the package will 
live there. It seems to have worked out fine in those cases. Even aside 
organizational issues (different upstreams, etc), simply including a 
package in Emacs will hardly help it gain users (people don't often 
examine the contents of our distribution). Whereas being featured in 
'M-x list-packages' with a good summary *can* make it well-known.

Do they want to be included and turned on by default? This seems like a 
good reason, if we really like it.

On the flip side, not every discussion that starts with 'I propose to 
put pkg-X in GNU ELPA' should end there.

As I wrote in another thread, maple-minibuffer is something we should 
consider sooner or later for the default behavior, for friendlier 
positioning of the minibuffer on graphical displays.

Another example is elegant-emacs, suggested in yet another thread by 
Nicolas P. Rougier. There's nothing stopping us from featuring it in GNU 
ELPA (right?), but we would get the most value if we really examine it 
and look for pieces to put into the vanilla Emacs by default.

"Write a new package" culture instead of patches?

[Stefan Kangas]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Another example is elegant-emacs, suggested in yet another thread by
> Nicolas P. Rougier. There's nothing stopping us from featuring it in GNU
> ELPA (right?), but we would get the most value if we really examine it
> and look for pieces to put into the vanilla Emacs by default.

Yes, this is the correct approach in many cases.

This reminds me of something else:

There's a general problem that when package <foo> lacks small feature
<bar>, some users don't see this as a chance to write a patch for <foo>.
Instead, they write a new library <foo>-<bar> to add this feature.

Sometimes, of course, this is the correct choice.  But I've seen some
very small packages just to basically patch this or that annoyance in a
package, or in core.  For example:

    https://github.com/Fuco1/eshell-bookmark/issues/1

(FWIW, I think we should have a policy to reject such packages on
technical grounds (and ideally MELPA would do the same).)

Now, this is an extreme example, but many more could be found.  Why are
the authors of "helpful.el" not helping us mainline some of their great
innovation, for example?

Has anyone else thought about this?  Is it correct to say that such a
"package first" culture has developed?  If yes, why has it developed,
and is there anything we could do about it?

Best regards,
Stefan Kangas

Re: "Write a new package" culture instead of patches?

[Dmitry Gutov]

On 17.05.2020 21:52, Stefan Kangas wrote:
> Why are
> the authors of "helpful.el" not helping us mainline some of their great
> innovation, for example?

I think Wilfred worked on some patch or other, to upstream some of the 
improvements. But not the whole of it.

Maybe because it's a much bigger job: to port the code, to satisfy all 
the historically accumulated edge cases, and to spend a few weeks 
arguing with whoever thinks the previous behavior was better at least in 
some respect.

We don't really have a conceptual framework for assessing big breaking 
changes.

Re: "Write a new package" culture instead of patches?

[Yuan Fu]

> On May 17, 2020, at 3:42 PM, Dmitry Gutov <dgutov@yandex.ru> wrote:
> 
> On 17.05.2020 21:52, Stefan Kangas wrote:
>> Why are
>> the authors of "helpful.el" not helping us mainline some of their great
>> innovation, for example?
> 
> I think Wilfred worked on some patch or other, to upstream some of the improvements. But not the whole of it.
> 
> Maybe because it's a much bigger job: to port the code, to satisfy all the historically accumulated edge cases, and to spend a few weeks arguing with whoever thinks the previous behavior was better at least in some respect.
> 
> We don't really have a conceptual framework for assessing big breaking changes.
> 

I think it’s just much easier to write helpful.el from scratch than read all the old code and understand it and try to patch it. I could have patched package.el to make it fetch from github repos, but instead I just wrote a quick small package to do that and moved on, which is much easier than reading and understanding package.el and convince people that such change is necessary.

Yuan

Re: "Write a new package" culture instead of patches?

[Arthur Miller]

Yuan Fu <casouri@gmail.com> writes:

>> On May 17, 2020, at 3:42 PM, Dmitry Gutov <dgutov@yandex.ru> wrote:
>> 
>> On 17.05.2020 21:52, Stefan Kangas wrote:
>>> Why are
>>> the authors of "helpful.el" not helping us mainline some of their great
>>> innovation, for example?
>> 
>> I think Wilfred worked on some patch or other, to upstream some of the improvements. But not the whole of it.
>> 
>> Maybe because it's a much bigger job: to port the code, to satisfy all the
>> historically accumulated edge cases, and to spend a few weeks arguing with
>> whoever thinks the previous behavior was better at least in some respect.
>> 
>> We don't really have a conceptual framework for assessing big breaking changes.
>> 
>
> I think it’s just much easier to write helpful.el from scratch than read all the
> old code and understand it and try to patch it. I could have patched package.el
> to make it fetch from github repos, but instead I just wrote a quick small
> package to do that and moved on, which is much easier than reading and
> understanding package.el and convince people that such change is necessary.
>
> Yuan
This "convincing people that such change is necessary" seems to be
actually an important reason :-).

Re: "Write a new package" culture instead of patches?

[chad]

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

On Sun, May 17, 2020 at 3:38 PM Yuan Fu <casouri@gmail.com> wrote:

> > On May 17, 2020, at 3:42 PM, Dmitry Gutov <dgutov@yandex.ru> wrote:
> >
> > On 17.05.2020 21:52, Stefan Kangas wrote:
> >> Why are
> >> the authors of "helpful.el" not helping us mainline some of their great
> >> innovation, for example?
> >
> > I think Wilfred worked on some patch or other, to upstream some of the
> improvements. But not the whole of it.
> >
> > Maybe because it's a much bigger job: to port the code, to satisfy all
> the historically accumulated edge cases, and to spend a few weeks arguing
> with whoever thinks the previous behavior was better at least in some
> respect.
> >
> > We don't really have a conceptual framework for assessing big breaking
> changes.
>
> I think it’s just much easier to write helpful.el from scratch than read
> all the old code and understand it and try to patch it. I could have
> patched package.el to make it fetch from github repos, but instead I just
> wrote a quick small package to do that and moved on, which is much easier
> than reading and understanding package.el and convince people that such
> change is necessary.


Extending this thought even further, I think that there is a perception
from people outside emacs-devel (and also some inside emacs-devel) that
"big" changes are often subjected to a "trial/pilot period" on GNU ELPA.
This seems entirely reasonable, but there are some important extra caveats:

1.) Almost everything that makes substantial user-visible changes in emacs
is very likely to generate (small-c) conservative resistance on emacs-devel.
2.) There doesn't seem to be any real process for taking things off of
their trial/pilot period.
3.) Developers seem most likely to fall into one of two buckets. Etiher my
code changes, and thus I'm happier with it in ELPA than inside emacs core,
or it doesn't, and there's basically no pressure for it not to just stay
inside ELPA, especially since it'll need to stay inside ELPA anyway for
older emacsen (and quite a lot of people are running older emacsen, for
performance and maintenance reasons).

These caveats combine to suggest very little benefit for moving code out of
ELPA and into core. (In fact, I think e.g. Dmitry's preference for moving
things into GNU ELPA is a natural expression of the same  factors.)

In the specific case of helpful.el: IIRC, it was brought up and immediately
ran into the tangle of these things: some interest, some conservatism, some
bikeshedding, and the realization that an ELPA package was
defintely required and, in practice, pretty close to sufficient.

For the future, my hope is that the recent interest in the user experience
of emacs for people who aren't deeply embedded in years (decades) of custom
and practice will result in more of these sorts of things getting included.
I've also noticed that some recent changes to emacs have pushed way more
people to upgrading emacs -- emacs 27's performance for code editing
compared to using LSP & LSP-like systems seems to have pushed upgrades, as
has the potential of testing native-comp. That's hopeful.

 ~Chad

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

Re: "Write a new package" culture instead of patches?

[Stefan Monnier]

Integration is hard.  So yes, people prefer to make new packages, this
way whoever likes it can install it and those who don't like it won't
be affected.

I don't think it's necessarily a problem.  It just means integration has
to be done separately.  Nowadays it's done at various places by
various people.  It's done here on emacs-devel, of course, but it's also
done in all the "Emacs distributions" like Doom, Spacemacs, ...

Having several distributions makes it easier, because the affected users
can go elsewhere when they're not happy, so while emacs-devel is quite
conservative, other distributions can be more daring.


        Stefan

Re: "Write a new package" culture instead of patches?

[João Távora]

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

On Mon, May 18, 2020 at 12:43 AM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:
> Integration is hard.  So yes, people prefer to make new packages, this
>  way whoever likes it can install it and those who don't like it won't
> be affected.

Of course. And those are the "hoops" that need be jumped,
and have absolutely nothing to do with Emacs's coding practices
or culture, they're just plain old engineering challenges.  If one
has little time or is bored to solve them, it's easy to flee to
MELPA: a fresh start, no-one depends on the new package,
which usually has a user base of one (or close to it).

João

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

Re: "Write a new package" culture instead of patches?

[Tim Cross]

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

On Mon, 18 May 2020 at 09:51, Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> Integration is hard.  So yes, people prefer to make new packages, this
> way whoever likes it can install it and those who don't like it won't
> be affected.
>
> I don't think it's necessarily a problem.  It just means integration has
> to be done separately.  Nowadays it's done at various places by
> various people.  It's done here on emacs-devel, of course, but it's also
> done in all the "Emacs distributions" like Doom, Spacemacs, ...
>
> Having several distributions makes it easier, because the affected users
> can go elsewhere when they're not happy, so while emacs-devel is quite
> conservative, other distributions can be more daring.
>
>
> +1. I don't think this is a big issue. There are pros/cons on both sides
and neither has significant advantage over the other. Personally, I like
having ELPA and Emacs be a minimal core which I can extend and add via
packages to get the environment I want. This tends to keep the core stuff
smaller and less complex, leading to less bugs and easier maintenance. The
downside is that when things in core ELPA/Emacs are updated, add on
packages may be broken until the author/maintainer gets around to updating
them.

As someone who has/does maintain code with a free and/or open source
license, I know from experience that contributions, enhancements and
extensions can be a real problem. I have one library which has become much
harder to maintain because I accepted enhancements from others. While those
enhancements were well written, now that they are part of my package, I'm
left to maintain them even though they were not enhancements I needed or
wanted. They have made my package harder to maintain and consequently,
takes time I really don't have. However, because it is now part of my
package, I either have to maintain it or remove it and the associated
functionality, potentially frusrating some users. In hindsight, I wish
these enhancements had been added as separate packages that extended my
lib.  I am now much less willing to accept pull requests that add new
features or functionality.

I think org-mode is probably a good example. There are many extensions and
enhancements to org-mode and many of them are separate packages. There are
still some things in org-mode core which probably should be separate
packages. The majority of these separate extensions/enhancements are not
things I'm interested in, so I don't want them installed. I'm pleased all
these extensions have not been added into the core as if they did,
development of core functionality would slow down and would likely become
more complex and buggy. The downside is that when a new org-mode release
occurs some of the add on packages I use may be broken for a time. However,
perhaps that doesn't matter or perhaps I may choose to pin the version of
org-mode to one where the add-on does work. If an add-on becomes really
popular and used by a majority of org-mode users, then perhaps it becomes a
good candidate for inclusion into org-mode or the functionality it
represents can be added to org-mode (negating the need for the add-on, but
possibly with a different implementation).

-- 
regards,

Tim

--
Tim Cross

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

Re: "Write a new package" culture instead of patches?

[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 don't think it's necessarily a problem.  It just means integration has
  > to be done separately.

I agree -- but let's be clear that "integration" means merging the change
(perhaps rewritten), not installing the patch package.

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

Re: "Write a new package" culture instead of patches?

[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 think it’s just much easier to write helpful.el from scratch
  > than read all the old code and understand it and try to patch
  > it. I could have patched package.el to make it fetch from github
  > repos, but instead I just wrote a quick small package to do that
  > and moved on, which is much easier than reading and understanding
  > package.el and convince people that such change is necessary.

When such patch packages accumulate, they will get in each others' way
because sometimes they will replace the same function with different
patched versions.  To make the unintegrated patches useful together
requires merging them.

Thus, the author of each patch package saves work by not following
through on the job.  Eventually the code in Emacs changes and the
patch package doesn't work any more.

We would like those people to help us merge their code (when it is
useful enough), but We can't tell them what to do.  What can we do?
What should we do?  Here is what I suggest.

* We should not distribute or refer people to patch packages.
If a repo includes more than a tiny fraction of patch packages,
we should consider it low-quality.

* If the job of merging is really easy we could do it straightaway.
Rewriting the change would avoid any need for an assignment.

* When users express interest in a patch package, we should say, "The
right thing to do here is merge that change.  Would you like to do
that work?  Then we could install the patch and support it."


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

Re: "Write a new package" culture instead of patches?

[Stefan Kangas]

Richard Stallman <rms@gnu.org> writes:

> * When users express interest in a patch package, we should say, "The
> right thing to do here is merge that change.  Would you like to do
> that work?  Then we could install the patch and support it."

I agree with everything you say here.  It is a good summary.

Just to clarify that helpful.el goes much further than a "patch
package".  It has significant features.

I believe I opened up for confusion by mentioning helpful.el in the same
breath as another package.  That other package indeed could and should
rightly be described as a "patch package".

I felt it was in place for me to clarify this, in fairness to the
helpful.el developers.

Best regards,
Stefan Kangas

Re: "Write a new package" culture instead of patches?

[Alan Third]

On Sun, May 17, 2020 at 11:52:18AM -0700, Stefan Kangas wrote:
> 
> Has anyone else thought about this?  Is it correct to say that such a
> "package first" culture has developed?  If yes, why has it developed,
> and is there anything we could do about it?

I wonder if it's related to the way that a couple of years ago many of
the discussions on the Emacs reddit seemed to revolve around why the
Emacs maintainers hadn't yet fixed someone's pet bug, but nobody ever
thought to report it to us.
-- 
Alan Third

Re: "Write a new package" culture instead of patches?

[Arthur Miller]

Alan Third <alan@idiocy.org> writes:

> On Sun, May 17, 2020 at 11:52:18AM -0700, Stefan Kangas wrote:
>> 
>> Has anyone else thought about this?  Is it correct to say that such a
>> "package first" culture has developed?  If yes, why has it developed,
>> and is there anything we could do about it?
>
> I wonder if it's related to the way that a couple of years ago many of
> the discussions on the Emacs reddit seemed to revolve around why the
> Emacs maintainers hadn't yet fixed someone's pet bug, but nobody ever
> thought to report it to us.
Could it rather be that a "github" culture has evolved, together with
social media it makes + melpa it makes it relatively easy to fork
someone's work, change/fix what bother you and make your own package
under other name.

There was recent reddit thread where some guy posted new
search/completion framework. Reason was nothing suites him. On the
github page he went through all the different frameworks already
avialable (some of which I didn't even hear off) concluding that Helm
was the only "resonable" pne, but was so big so he prefer to write his
own.

Another factor is that maybe original author does not wish to bend
his/her package according to what someone wishes, and that someone forks
and patches the original according to own desire under different name. I
don't know, seems a little bit so. Github and flexible licensing made it
easy to fork other peoples work, social media like Reddit & Twitter made
it easy to spread the word about it and Melpa makes it easy to share (in
case of Emacs).

I don't think it has anything Emacs devs not fixing something, it is
just emerging social dev trend. Also more people are technically
skilled nowadays (millenials) and we more programmers or hobby
programmers then probably ever before.

Re: "Write a new package" culture instead of patches?

[tomas]

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

On Mon, May 18, 2020 at 12:02:52AM +0200, Arthur Miller wrote:
> Alan Third <alan@idiocy.org> writes:
> 
> > On Sun, May 17, 2020 at 11:52:18AM -0700, Stefan Kangas wrote:
> >> 
> >> Has anyone else thought about this?  Is it correct to say that such a
> >> "package first" culture has developed?  If yes, why has it developed,
> >> and is there anything we could do about it?
> >
> > I wonder if it's related to the way that a couple of years ago many of
> > the discussions on the Emacs reddit seemed to revolve around why the
> > Emacs maintainers hadn't yet fixed someone's pet bug, but nobody ever
> > thought to report it to us.
> Could it rather be that a "github" culture has evolved, together with
> social media it makes + melpa it makes it relatively easy to fork
> someone's work, change/fix what bother you and make your own package
> under other name.

This rhymes with one observation I made: Git makes branching easy.
Still, Github strongly encourages forking. Why is this so? My hunch
is that for Github, the number of repositories they host is /currency/
(actually to the tune of $7.5B, as it turned out by 2018). So there's
a strong motivation to multiply the number of repos.

That is, I think, the same mechanism as Twitter or Facebook
tolerating bots as legit accounts (up to a certain point),
because they inflate their market value. And not much different
as Microsoft tolerating pirated versions of Windows (remember
the end-90s where everyone knew that you could generate a valid
Windows license key by making sure that the middle part of
the number was divisible by 7?).

These are, of course, mechanisms which are totally alien to the
Free Software world [1]. But I guess it's standard corporate
fare. Something-something-strategy, I guess.

Cheers
[1] Although we're catching up :-/
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: "Write a new package" culture instead of patches?

[Arthur Miller]

<tomas@tuxteam.de> writes:

> On Mon, May 18, 2020 at 12:02:52AM +0200, Arthur Miller wrote:
>> Alan Third <alan@idiocy.org> writes:
>> 
>> > On Sun, May 17, 2020 at 11:52:18AM -0700, Stefan Kangas wrote:
>> >> 
>> >> Has anyone else thought about this?  Is it correct to say that such a
>> >> "package first" culture has developed?  If yes, why has it developed,
>> >> and is there anything we could do about it?
>> >
>> > I wonder if it's related to the way that a couple of years ago many of
>> > the discussions on the Emacs reddit seemed to revolve around why the
>> > Emacs maintainers hadn't yet fixed someone's pet bug, but nobody ever
>> > thought to report it to us.
>> Could it rather be that a "github" culture has evolved, together with
>> social media it makes + melpa it makes it relatively easy to fork
>> someone's work, change/fix what bother you and make your own package
>> under other name.
>
> This rhymes with one observation I made: Git makes branching easy.
> Still, Github strongly encourages forking. Why is this so? My hunch
> is that for Github, the number of repositories they host is /currency/
> (actually to the tune of $7.5B, as it turned out by 2018). So there's
> a strong motivation to multiply the number of repos.
>
> That is, I think, the same mechanism as Twitter or Facebook
> tolerating bots as legit accounts (up to a certain point),
> because they inflate their market value. And not much different
> as Microsoft tolerating pirated versions of Windows (remember
> the end-90s where everyone knew that you could generate a valid
> Windows license key by making sure that the middle part of
> the number was divisible by 7?).
>
> These are, of course, mechanisms which are totally alien to the
> Free Software world [1]. But I guess it's standard corporate
> fare. Something-something-strategy, I guess.
>
> Cheers
> [1] Although we're catching up :-/
> -- t
That plays role definitely. Familiarity as well. Github is really easy
to work with and get started with git and as they let people do whatever
they want, like fork crap load of repos, it also makes people use github
and get familiar with its APIs etc. Once I setuped github api keys, I
don't feel for going over and setting up API keys for gitlab, I dont'
know is there a free service like github? I have very modest needs and
am too lazy for me to be worth going hoops around searching for better
alternative.

I think familiarity is also reason why major companies tolarated privacy
back as you say. I remember in early 2000, if you wrote word microsoft
or adobe in back than AltaVista or Google you would be bombed with pages
that offered keygens and pirated copies. They let people use it, it ment
people will learn it, and once they learn it, they stick with it. So
once they come to workplace the company will get them the software
because they are knowledgable with it.

Re: "Write a new package" culture instead of patches?

[tomas]

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

On Mon, May 18, 2020 at 02:08:38PM +0200, Arthur Miller wrote:
> <tomas@tuxteam.de> writes:

[on branching vs contributing, Github culture]

> That plays role definitely. Familiarity as well. Github is really easy
> to work with [...]

Yes, the bribe of convenience.

> [...] I dont' know is there a free service like github? I have
> very modest needs [...]

If you are willing to learn a new web interface, there's Gitlab
(the server component is umm... somewhat free; more precisely
it's "open core", as they say) and there's Gitea. Savannah has
a git service too, I don't know very much about the interface
they offer.

It does take a bit of willpower to leave the plushy universe,
but believe me -- it's a great landscape out there!

C'm on. Take the red pill ;-D

Cheers
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

RE: "Write a new package" culture instead of patches?

[arthur miller]

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

Haha, yeah I know. I actually once  created a gitlab project for a customer on girlab, I just didn't know it was open source. Or I have just forgot . But even if gitlab is open source, what says that their web interface is? How do I know with my data and me, that I can't know? :-) Is it just "open source" or  "free" as in fsf free.

Anyway, convenience is just one part of equation. The big issue is convenience of group. Everyone is on github. One fork a repo, make a commit and create PR. PR is the new patch. People don't send patches in emails longer (ok kernel a d Emacs folks does), it is kind of getting out of fashion. And github makes that  very convenient.

Anyway, the forking culture has more to do with business then just for the service providers. Small companies create projects, and let people fork, the more people fork, the  better it looks in presentation for in estors: ohook, we ha e 5000 firks and 10 000 downloads, we are popular, grant us funding for next year and we can do this and that....




-------- Originalmeddelande --------
Från: tomas@tuxteam.de
Datum: 2020-05-18 14:33 (GMT+01:00)
Till: emacs-devel@gnu.org
Ämne: Re: "Write a new package" culture instead of patches?

On Mon, May 18, 2020 at 02:08:38PM +0200, Arthur Miller wrote:
> <tomas@tuxteam.de> writes:

[on branching vs contributing, Github culture]

> That plays role definitely. Familiarity as well. Github is really easy
> to work with [...]

Yes, the bribe of convenience.

> [...] I dont' know is there a free service like github? I have
> very modest needs [...]

If you are willing to learn a new web interface, there's Gitlab
(the server component is umm... somewhat free; more precisely
it's "open core", as they say) and there's Gitea. Savannah has
a git service too, I don't know very much about the interface
they offer.

It does take a bit of willpower to leave the plushy universe,
but believe me -- it's a great landscape out there!

C'm on. Take the red pill ;-D

Cheers
-- t

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

Re: "Write a new package" culture instead of patches?

[tomas]

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

On Mon, May 18, 2020 at 11:07:23PM +0000, arthur miller wrote:
> Haha, yeah I know. I actually once  created a gitlab project for a customer on girlab, I just didn't know it was open source. Or I have just forgot . But even if gitlab is open source, what says that their web interface is? How do I know with my data and me, that I can't know? :-) Is it just "open source" or  "free" as in fsf free.

A service per se isn't "open source". The programs it is based on
can be... and Gitlab scores decently here (it's "open core").

> Anyway, convenience is just one part of equation. The big issue is convenience of group. Everyone is on github. One fork a repo, make a commit and create PR. PR is the new patch. People don't send patches in emails longer (ok kernel a d Emacs folks does), it is kind of getting out of fashion. And github makes that  very convenient.

This is called network effect. And yes, it's part of convenience.

> Anyway, the forking culture has more to do with business then just for the service providers. Small companies create projects, and let people fork, the more people fork, the  better it looks in presentation for in estors: ohook, we ha e 5000 firks and 10 000 downloads, we are popular, grant us funding for next year and we can do this and that....

That's my guess too: some shiny pseudo-metrics (that what made
Github 7.5B dollar worth in the first place).

Cheers
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: "Write a new package" culture instead of patches?

[Matthias Meulien]

Stefan Kangas <stefankangas@gmail.com> writes:
 
> There's a general problem that when package <foo> lacks small 
> feature <bar>, some users don't see this as a chance to write a 
> patch for <foo>.  Instead, they write a new library <foo>-<bar> 
> to add this feature. 
> 
> Sometimes, of course, this is the correct choice.  But I've seen 
> some very small packages just to basically patch this or that 
> annoyance in a package, or in core.  For example: 
> 
>     https://github.com/Fuco1/eshell-bookmark/issues/1

Stefan, may be you'll like to have support for bookmark.el in VC 
dir buffers too (see bug #39722)? ;-)

> (FWIW, I think we should have a policy to reject such packages 
> on technical grounds (and ideally MELPA would do the same).) 
> 
> Now, this is an extreme example, but many more could be found. 
> Why are the authors of "helpful.el" not helping us mainline some 
> of their great innovation, for example? 
> 
> Has anyone else thought about this?  Is it correct to say that 
> such a "package first" culture has developed?  If yes, why has 
> it developed, and is there anything we could do about it?

I guess good reasons to prefer small packages to fix annoyances is 
that: 

1) The delay can be long between a patch is submitted and it is 
   commented or merged (already two months for the mentionned 
   one). OTOH packages are immediatly availables to all your 
   computers

2) It's not clear to me whether trivial patches are welcome or 
not; My 
   feeling is that they're wasting precious time of core Emacs 
   developers
-- 
Matthias