Re: Why are so many great packages not trying to get included in GNU Emacs?

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Luke Shumaker]

Hi, sorry to jump in as an outsider.  I just wanted to clarify a
couple of things about Git.

> How could that be possible?  How would we know who wrote those
> changes?  We can't assume it is the person whose account checked them
> in.  Often that is so, but not always.

Git tracks separate "committer" and "author" information (both of
which are name/email/timestamp).  Unfortunately, it only allows
exactly one author; limiting the case where a change has 2
collaborators.

> There may be other issues, such as, if the name on that account is
> John Doe, does that mean the user of that account is the same John Doe
> that signed an assignment?

Git tracks both name and email.  Surely assuming jdoe@foocorp.com is
the same jdoe@foocorp.com that signed the assignment is a safer
assumption?

Of course, that can be intentionally spoofed.  I'm not sure whether
the concern is about accidentally mixing up two people, or about
someone maliciously misrepresenting the authorship.  If the concern is
malicious misrepresentation, then this could be solved with
GPG-signing of either the emails with the patches, or the Git commits
(which is something that Git supports).

----

FWIW, several free software projects that I've contributed to (and
require copyright assignment or other licensing paperwork) handle this
by requiring that each commit message have a specially formatted line
in it:

    Signed-off-by: Full Name <user@domain>

for each person that contributed to that commit (this line can
conveniently be added with `--signoff` flag to `git commit`); and they
have an automated system that validates that each submitted commit has
such a line, and that the person mentioned in the line has signed the
agreement.  I believe this is standard for projects under the auspices
of the Linux Foundation.

-- 
Happy hacking,
~ Luke Shumaker

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> Date: Thu, 07 May 2020 14:17:07 -0400
> From: Luke Shumaker <lukeshu@lukeshu.com>
> Cc: emacs-devel@gnu.org
> 
> > How could that be possible?  How would we know who wrote those
> > changes?  We can't assume it is the person whose account checked them
> > in.  Often that is so, but not always.
> 
> Git tracks separate "committer" and "author" information (both of
> which are name/email/timestamp).  Unfortunately, it only allows
> exactly one author; limiting the case where a change has 2
> collaborators.
> 
> > There may be other issues, such as, if the name on that account is
> > John Doe, does that mean the user of that account is the same John Doe
> > that signed an assignment?
> 
> Git tracks both name and email.  Surely assuming jdoe@foocorp.com is
> the same jdoe@foocorp.com that signed the assignment is a safer
> assumption?
> 
> Of course, that can be intentionally spoofed.  I'm not sure whether
> the concern is about accidentally mixing up two people, or about
> someone maliciously misrepresenting the authorship.  If the concern is
> malicious misrepresentation, then this could be solved with
> GPG-signing of either the emails with the patches, or the Git commits
> (which is something that Git supports).

It doesn't have to be malicious.  Mistakes happen much more
frequently.  I caught myself several times forgetting to say --author
when committing (fortunately before pushing, so I could fix that in
time).  Or the committer may not be aware how important it is to state
the author accurately, because many people are unaware of the legal
implications.  Or the code could be by more than one author.  Or the
author could have more than one email address, and use them
interchangeably, unaware of the identification problem this creates.
Or any number of other similar issues, which are minor for most of us,
but can be crucial if the code will need to be defended in court.

Re: Why are so many great packages not trying to get included in GNU 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, several free software projects that I've contributed to (and
  > require copyright assignment or other licensing paperwork) handle this
  > by requiring that each commit message have a specially formatted line
  > in it:

  >     Signed-off-by: Full Name <user@domain>

If that works well in practice, we could adopt it.  I don't
see any problem on first glance,

-- 
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: Why are so many great packages not trying to get included in GNU Emacs?

[ndame]

> The reasons why package authors would not want to include it

Also, it may not even occur to the developer to include the code
in emacs, because it works for him and he's happy with it.

Is there an actual effort too seek out prospective packages and ask the
code owners to include it in emacs? Or is it left to the chance
that it occurs to the developer?

What about current popular packages outside Emacs? Were those developers
all asked?

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Yuan Fu]

> On Apr 23, 2020, at 1:47 PM, ndame <ndame@protonmail.com> wrote:
> 
>> The reasons why package authors would not want to include it
> 
> Also, it may not even occur to the developer to include the code
> in emacs, because it works for him and he's happy with it.
> 

Another downside to adding one’s package to ELPA is the inconvenience. On GitHub one can freely commit however he wants, receive PR and issues; but if it’s in ELPA, you need to take care of commit message formats, submit a patch and wait for someone to review & commit the patch. Also, admittedly, while the email based workflow works, and works fine, admittedly it is not as convenient as github’s PR. It would be interesting to see a Emacs+email-based PR system/interface. E.g., save comments and stuff into a “PR file” and pass that back and forth through email, and view the PR file with an elaborate interface in Emacs. Essentially an interactive improved patch.

Yuan

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Stefan Kangas]

Yuan Fu <casouri@gmail.com> writes:
> Another downside to adding one’s package to ELPA is the inconvenience. On GitHub one can freely commit however he wants, receive PR and issues

There are many packages in GNU ELPA hosted on GitHub, for example eglot:
https://github.com/joaotavora/eglot

See the "externals-list" file in the elpa repository.

Best regards,
Stefan Kangas

Re: Why are so many great packages not trying to get included in GNU Emacs?

[ndame]

>
> Another downside to adding one’s package to ELPA is the inconvenience.  On GitHub one can freely commit however he wants, receive PR and issues; but if it’s in ELPA, you need to take care of commit message formats, submit a patch and wait for someone to review & commit the patch.

I thought that the advantage of ELPA was that the author could develop the package independently of the strict emacs commit rules and he only had to pay attention to the copyright assignment.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Yuan Fu]

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

> There are many packages in GNU ELPA hosted on GitHub, for example eglot:
> https://github.com/joaotavora/eglot <https://github.com/joaotavora/eglot>
> 
> See the "externals-list" file in the elpa repository.

>> 
>> Another downside to adding one’s package to ELPA is the inconvenience.  On GitHub one can freely commit however he wants, receive PR and issues; but if it’s in ELPA, you need to take care of commit message formats, submit a patch and wait for someone to review & commit the patch.
> 
> I thought that the advantage of ELPA was that the author could develop the package independently of the strict emacs commit rules and he only had to pay attention to the copyright assignment.

I see. Apparently this is another example of the “misconceptions” about ELPA :-)

Yuan

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

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Stefan Monnier]

>> Another downside to adding one’s package to ELPA is the inconvenience.
>> On GitHub one can freely commit however he wants, receive PR and issues;
>> but if it’s in ELPA, you need to take care of commit message formats,
>> submit a patch and wait for someone to review & commit the patch.
>
> I thought that the advantage of ELPA was that the author could develop the
> package independently of the strict emacs commit rules and he only had to
> pay attention to the copyright assignment.

That's right.  There is a practical problem, OTOH, which is that
write/push access to a GNU ELPA package currently means write access to
all GNU ELPA packages as well as to Emacs's repository.

For this reason, while some GNU ELPA package maintainers can "just push"
as they see fit, as it should be, others haven't yet been granted this
right.  This is a problem which we should solve, indeed, for the benefit
of those less-lucky package maintainers, as well as for the benefit of
those Emacs maintainers who have to play the middle men, and more
generally for the benefit of the GNU ELPA archive and hence Emacs users
since the current situation tends to discourage submissions.

Note that giving write access widely, as we do now, has advantages as
well, in that it encourages package maintainers to participate in
development of Emacs more generally.


        Stefan

Re: Why are so many great packages not trying to get included in GNU Emacs?

[ndame]

>
> For this reason, while some GNU ELPA package maintainers can "just push"
> as they see fit, as it should be, others haven't yet been granted this
> right. This is a problem which we should solve,

A simple solution which occurs to me that a script which has the necessary
permissions could pull the changes to its local repo and push from there
to ELPA. (This implies that the author pushes his changes to a public
place like GitHub, so the script can pull them from there.)

The script pulls the changes from the external repo when a certain dedicated
file in the repo (e.g. ELPA.pull) changes. The author changes this file
when he wants to authorize a new pull (wants to do a release to ELPA).

The script can discover the changed trigger file either by regularly checking
the external repos of the ELPA packages which follow this protocol, or if it's
too much work then the author can send a mail to a dedicated mail address
which triggers the pull of his repo (e.g. sends a mail to elpapull@gnu.org
with the subject <package name>.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eric Abrahamsen]

ndame <ndame@protonmail.com> writes:

>>
>> For this reason, while some GNU ELPA package maintainers can "just push"
>> as they see fit, as it should be, others haven't yet been granted this
>> right. This is a problem which we should solve,
>
> A simple solution which occurs to me that a script which has the necessary
> permissions could pull the changes to its local repo and push from there
> to ELPA. (This implies that the author pushes his changes to a public
> place like GitHub, so the script can pull them from there.)
>
> The script pulls the changes from the external repo when a certain dedicated
> file in the repo (e.g. ELPA.pull) changes. The author changes this file
> when he wants to authorize a new pull (wants to do a release to ELPA).
>
> The script can discover the changed trigger file either by regularly checking
> the external repos of the ELPA packages which follow this protocol, or if it's
> too much work then the author can send a mail to a dedicated mail address
> which triggers the pull of his repo (e.g. sends a mail to elpapull@gnu.org
> with the subject <package name>.

I think it could be even simpler than that: ELPA is built every 24 hours
right now. If we just registered external repos with ELPA, part of the
build process could be pulling from those repos automatically, once per
day. Package authors already have a mechanism for manually triggering a
release: incrementing the package version number. There's no harm in
ELPA bringing in new commits from the externals, if the author is still
in control of when a new version is released.

Eric

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Stefan Monnier]

> I think it could be even simpler than that: ELPA is built every 24 hours
> right now. If we just registered external repos with ELPA, part of the
> build process could be pulling from those repos automatically, once per
> day. Package authors already have a mechanism for manually triggering a
> release: incrementing the package version number. There's no harm in
> ELPA bringing in new commits from the externals, if the author is still
> in control of when a new version is released.

I think it's important that we don't "pull" from "random" places like
Github repositories.  More specifically, the "push to elpa.git" serves
as a confirmation that someone thinks this code is appropriate for
elpa.git (typically the concern being copyright).

For a pure "distribution only", we already have MELPA.

But yes, like "ndame" suggests, we could pull from some other
repositories kept under the gnu.org domain and then give write access
more liberally (or differently) to those repositories.  I think
currently creating new repositories with different access rights on
savannah is administrively too heavy to have a separate "savannah
project" per GNU ELPA package.  My hope is that the "new forge"
(Gitea/Pagure/SourceHut?) will solve this problem, but I don't know when
it will be available.


        Stefan

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eric Abrahamsen]

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

>> I think it could be even simpler than that: ELPA is built every 24 hours
>> right now. If we just registered external repos with ELPA, part of the
>> build process could be pulling from those repos automatically, once per
>> day. Package authors already have a mechanism for manually triggering a
>> release: incrementing the package version number. There's no harm in
>> ELPA bringing in new commits from the externals, if the author is still
>> in control of when a new version is released.
>
> I think it's important that we don't "pull" from "random" places like
> Github repositories.  More specifically, the "push to elpa.git" serves
> as a confirmation that someone thinks this code is appropriate for
> elpa.git (typically the concern being copyright).

It doesn't seem much more random to say "we're adding your repo URL to
our list of approved ELPA pull-sources" than to say "you're now free to
push whatever you like", does it? An ELPA administrator still has to
make that explicit decision to add the URL, so there's still a level of
approval?

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Tim Cross]

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

I think a pull model wold actually be more secure and less maintenance. It
would mean that the contents of ELPA is 100% under the control of GNU. You
would have fewer access credentials to manage and would eliminate the risk
associated with external people and their management of their access
credentials. If wanted, you could also add processes to do any verification
tasks e.g. has tests, documentation, no large commits from people without
copyright assignment, code quality whatever.

On Fri, 24 Apr 2020 at 09:12, Eric Abrahamsen <eric@ericabrahamsen.net>
wrote:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> >> I think it could be even simpler than that: ELPA is built every 24 hours
> >> right now. If we just registered external repos with ELPA, part of the
> >> build process could be pulling from those repos automatically, once per
> >> day. Package authors already have a mechanism for manually triggering a
> >> release: incrementing the package version number. There's no harm in
> >> ELPA bringing in new commits from the externals, if the author is still
> >> in control of when a new version is released.
> >
> > I think it's important that we don't "pull" from "random" places like
> > Github repositories.  More specifically, the "push to elpa.git" serves
> > as a confirmation that someone thinks this code is appropriate for
> > elpa.git (typically the concern being copyright).
>
> It doesn't seem much more random to say "we're adding your repo URL to
> our list of approved ELPA pull-sources" than to say "you're now free to
> push whatever you like", does it? An ELPA administrator still has to
> make that explicit decision to add the URL, so there's still a level of
> approval?
>
>

-- 
regards,

Tim

--
Tim Cross

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

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Stefan Monnier]

> It doesn't seem much more random to say "we're adding your repo URL to
> our list of approved ELPA pull-sources" than to say "you're now free to
> push whatever you like", does it? An ELPA administrator still has to
> make that explicit decision to add the URL, so there's still a level of
> approval?

I think there's a fairly large difference:

- When we pull from an external repository, every person who has write
  access to that repository is now in charge of thinking "does this fit
  the copyright requirements?", whereas only the original official
  maintainer has been explicitly informed about those requirements.
- The set of such people can be changed completely outside of our control,
  whereas we always make sure that people have signed the proper
  copyright paperwork before they get push access.
- After the initial setup, everything else would be transparent, so it'd
  be easy for the developers to forget or be unaware that it's published
  in GNU ELPA.
  The mindset on github is one that doesn't encourage careful
  consideration of licensing and authorship but instead encourages
  "happy sharing" [ Paradoxically, the FSF's insistence on tracking
  copyright assignments makes this very problematic (even tho, "happy
  sharing" is really what we all want to do) unless it's between people
  who we know have signed the copyright paperwork.  ]
  So psychologically, I think there is a big difference between
  "everything takes place on github" and "an explicit step is needed
  every time you want to get the code to the gnu.org side".


        Stefan

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eric Abrahamsen]

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

>> It doesn't seem much more random to say "we're adding your repo URL to
>> our list of approved ELPA pull-sources" than to say "you're now free to
>> push whatever you like", does it? An ELPA administrator still has to
>> make that explicit decision to add the URL, so there's still a level of
>> approval?
>
> I think there's a fairly large difference:
>
> - When we pull from an external repository, every person who has write
>   access to that repository is now in charge of thinking "does this fit
>   the copyright requirements?", whereas only the original official
>   maintainer has been explicitly informed about those requirements.
> - The set of such people can be changed completely outside of our control,
>   whereas we always make sure that people have signed the proper
>   copyright paperwork before they get push access.
> - After the initial setup, everything else would be transparent, so it'd
>   be easy for the developers to forget or be unaware that it's published
>   in GNU ELPA.
>   The mindset on github is one that doesn't encourage careful
>   consideration of licensing and authorship but instead encourages
>   "happy sharing" [ Paradoxically, the FSF's insistence on tracking
>   copyright assignments makes this very problematic (even tho, "happy
>   sharing" is really what we all want to do) unless it's between people
>   who we know have signed the copyright paperwork.  ]
>   So psychologically, I think there is a big difference between
>   "everything takes place on github" and "an explicit step is needed
>   every time you want to get the code to the gnu.org side".

Okay, that makes sense.

Thanks,
Eric

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 23 Apr 2020 23:24:53 -0400
> Cc: Yuan Fu <casouri@gmail.com>, ndame <ndame@protonmail.com>,
>  Emacs developers <emacs-devel@gnu.org>
> 
>   The mindset on github is one that doesn't encourage careful
>   consideration of licensing and authorship but instead encourages
>   "happy sharing" [ Paradoxically, the FSF's insistence on tracking
>   copyright assignments makes this very problematic (even tho, "happy
>   sharing" is really what we all want to do) unless it's between people
>   who we know have signed the copyright paperwork.  ]

I don't see that as a paradox.  The world of Free Software is much
larger than the world of GNU projects.  The FSF is advancing the
former to encourage "happy sharing", but exercise extra caution with
the latter.

Re: Why are so many great packages not trying to get included in GNU 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. ]]]

  > I don't see that as a paradox.  The world of Free Software is much
  > larger than the world of GNU projects.  The FSF is advancing the
  > former to encourage "happy sharing", but exercise extra caution with
  > the latter.

That is basically true, but to be entirely correct it should say "SOME
GNU packages".  The "extra caution" applies to GNU packages which are
copyright FSF, and is for the sake of being able to enforce copyleft
in court.  Other GNU packages are copyrighted by their authors.


-- 
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: Why are so many great packages not trying to get included in GNU Emacs?

[Phillip Lord]

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

>   The mindset on github is one that doesn't encourage careful
>   consideration of licensing and authorship but instead encourages
>   "happy sharing" [ Paradoxically, the FSF's insistence on tracking
>   copyright assignments makes this very problematic (even tho, "happy
>   sharing" is really what we all want to do) unless it's between people
>   who we know have signed the copyright paperwork.  ]


It is worth saying that while the process of getting copyright
assignment is clunky, it is not insurmountable. However, the process of
working out whether someone has copyright assignment already is a total
pain.

It should be possible to check automatically whether commits coming in
from any git repo are from someone who has assigned copyright. That
would, at least, remove the hassle in the case where the papers have
been done.

I have been through the process with dash.el as you know, and while I
managed to get it into ELPA, I have not managed to update it for a while
because there are new contributors and the process is all too painful.

Phil

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Stefan Monnier]

> I have been through the process with dash.el as you know, and while I
> managed to get it into ELPA, I have not managed to update it for a while
> because there are new contributors and the process is all too painful.

The check has to be done right when a new contributor appears, not after
the fact, indeed, otherwise it quickly becomes unmanageable.


        Stefan

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Phillip Lord]

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

>> I have been through the process with dash.el as you know, and while I
>> managed to get it into ELPA, I have not managed to update it for a while
>> because there are new contributors and the process is all too painful.
>
> The check has to be done right when a new contributor appears, not after
> the fact, indeed, otherwise it quickly becomes unmanageable.


Even then, there is no easy way of doing it, other than just asking and
taking it on trust. Or in some cases, just assuming, because they have
contributed directly to Emacs, for instance. In one case, I nearly did
this, and it turned out to be wrong.

It's probably not worth re-opening the debate on whether this needs to
happen at all, but it if this is mandated by the FSF then spending some
money on making it easier is surely worth it.

Phil

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Stefan Monnier]

> Even then, there is no easy way of doing it, other than just asking and
> taking it on trust.

Yes, no doubt that this a problem.

You can always ask me or Eli to lookup the name in the official list,
but clearly it's inconvenient.


        Stefan

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Stefan Monnier]

> It is worth saying that while the process of getting copyright
> assignment is clunky, it is not insurmountable. However, the process of
> working out whether someone has copyright assignment already is a total
> pain.

I'm lucky enough to have access to fencepost.gnu.org where the
`copyright.list` file is kept, so I can look it up fairly easily, but
for those who aren't so lucky it's indeed a problem.

> It should be possible to check automatically whether commits coming in
> from any git repo are from someone who has assigned copyright. That
> would, at least, remove the hassle in the case where the papers have
> been done.

I think for privacy reasons we can't distribute `copyright.list` itself.

But we could maintain a list of people who have signed the paperwork,
built from publicly available information, i.e. from the Git log of
emacs.git and elpa.git.  While not being on that list wouldn't be
a guarantee that paperwork is needed, it would still be helpful,
I think.

Any taker?


        Sefan

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Clément Pit-Claudel]

On 24/04/2020 23.11, Stefan Monnier wrote:
> But we could maintain a list of people who have signed the paperwork,
> built from publicly available information, i.e. from the Git log of
> emacs.git and elpa.git.  While not being on that list wouldn't be
> a guarantee that paperwork is needed, it would still be helpful,
> I think.
> 
> Any taker?

git log --format="%aE" | sort | uniq ?
Though I think having a commit in the Emacs repo doesn't necessarily imply having copyright papers on file.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Sat, 25 Apr 2020 00:22:39 -0400
> 
> On 24/04/2020 23.11, Stefan Monnier wrote:
> > But we could maintain a list of people who have signed the paperwork,
> > built from publicly available information, i.e. from the Git log of
> > emacs.git and elpa.git.  While not being on that list wouldn't be
> > a guarantee that paperwork is needed, it would still be helpful,
> > I think.
> > 
> > Any taker?
> 
> git log --format="%aE" | sort | uniq ?

This needs to be audited to exclude people who don't have assignment.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eric Abrahamsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Sat, 25 Apr 2020 00:22:39 -0400
>> 
>> On 24/04/2020 23.11, Stefan Monnier wrote:
>> > But we could maintain a list of people who have signed the paperwork,
>> > built from publicly available information, i.e. from the Git log of
>> > emacs.git and elpa.git.  While not being on that list wouldn't be
>> > a guarantee that paperwork is needed, it would still be helpful,
>> > I think.
>> > 
>> > Any taker?
>> 
>> git log --format="%aE" | sort | uniq ?
>
> This needs to be audited to exclude people who don't have assignment.

I suppose listing committer instead of author would do it
(--format="%cE"), since we're literally only interested in who can
commit. That lists 356 unique committers -- obviously manual checking is
still necessary, but that's the right place to start? The same command
run in the ELPA repository gives 426 committers.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Cc: Clément Pit-Claudel <cpitclaudel@gmail.com>,
>   emacs-devel@gnu.org
> Date: Sat, 25 Apr 2020 10:41:24 -0700
> 
> >> git log --format="%aE" | sort | uniq ?
> >
> > This needs to be audited to exclude people who don't have assignment.
> 
> I suppose listing committer instead of author would do it
> (--format="%cE"), since we're literally only interested in who can
> commit.

Are we?  I thought this was about knowing when a contributor has an
assignment on file, for people who don't have access to "the file"
itself.  Most contributors who went through the legal paperwork and
assigned copyright to the FSF don't have write access to the
repository.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eric Abrahamsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> Cc: Clément Pit-Claudel <cpitclaudel@gmail.com>,
>>   emacs-devel@gnu.org
>> Date: Sat, 25 Apr 2020 10:41:24 -0700
>> 
>> >> git log --format="%aE" | sort | uniq ?
>> >
>> > This needs to be audited to exclude people who don't have assignment.
>> 
>> I suppose listing committer instead of author would do it
>> (--format="%cE"), since we're literally only interested in who can
>> commit.
>
> Are we?  I thought this was about knowing when a contributor has an
> assignment on file, for people who don't have access to "the file"
> itself.  Most contributors who went through the legal paperwork and
> assigned copyright to the FSF don't have write access to the
> repository.

Oh, then I guess author is more relevant after all, sorry about that.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Phillip Lord]

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

>> It is worth saying that while the process of getting copyright
>> assignment is clunky, it is not insurmountable. However, the process of
>> working out whether someone has copyright assignment already is a total
>> pain.
>
> I'm lucky enough to have access to fencepost.gnu.org where the
> `copyright.list` file is kept, so I can look it up fairly easily, but
> for those who aren't so lucky it's indeed a problem.
>
>> It should be possible to check automatically whether commits coming in
>> from any git repo are from someone who has assigned copyright. That
>> would, at least, remove the hassle in the case where the papers have
>> been done.
>
> I think for privacy reasons we can't distribute `copyright.list` itself.
>
> But we could maintain a list of people who have signed the paperwork,
> built from publicly available information, i.e. from the Git log of
> emacs.git and elpa.git.  While not being on that list wouldn't be
> a guarantee that paperwork is needed, it would still be helpful,
> I think.

I don't understand this logic. If most (although not all) of the
information in copyright.list can be gleaned from running git log, or
looking at AUTHORS, where is the privacy issue?

What not ask everyone when they submit their papers, if they are happy
to be public, along with a list of their commonly used aliases, emails
and so forth? Put this information up on the web, along with a RESTful
API. Add some command line tools, so that people can add it to the CI
tooling.

Phil

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Stefan Monnier]

> I don't understand this logic. If most (although not all) of the
> information in copyright.list can be gleaned from running git log, or
> looking at AUTHORS,

The official list is not specific to Emacs, includes real names (for
people who are otherwise only known via pseudonyms), birthdates,
countries, and other such info.
so it's quite different from the info you can get from Git.

> where is the privacy issue?

To be honest, I'm not sure.  I'd also like to know since without with
info it's hard to figure out what could be done.

E.g. would it OK if I filtered the list to only include paperwork that
covers contributions to Emacs and that only includes the names and
email addresses?
I think it would satisfy your use case, but would it be acceptable in
terms of privacy?  I don't know!

> What not ask everyone when they submit their papers, if they are happy
> to be public, along with a list of their commonly used aliases, emails
> and so forth?

That would be great.  Note that we (maintainers) don't have any direct
involvement in this, sadly.  The list is maintained by the FSF's
"clerk", so we should move this conversation there.

> Put this information up on the web, along with a RESTful API.
> Add some command line tools, so that people can add it to the
> CI tooling.

Even better, yes,


        Stefan

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Phillip Lord]

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

>> I don't understand this logic. If most (although not all) of the
>> information in copyright.list can be gleaned from running git log, or
>> looking at AUTHORS,
>
> The official list is not specific to Emacs, includes real names (for
> people who are otherwise only known via pseudonyms), birthdates,
> countries, and other such info.
> so it's quite different from the info you can get from Git.
>
>> where is the privacy issue?
>
> To be honest, I'm not sure.  I'd also like to know since without with
> info it's hard to figure out what could be done.
>
> E.g. would it OK if I filtered the list to only include paperwork that
> covers contributions to Emacs and that only includes the names and
> email addresses?
> I think it would satisfy your use case, but would it be acceptable in
> terms of privacy?  I don't know!
>
>> What not ask everyone when they submit their papers, if they are happy
>> to be public, along with a list of their commonly used aliases, emails
>> and so forth?
>
> That would be great.  Note that we (maintainers) don't have any direct
> involvement in this, sadly.  The list is maintained by the FSF's
> "clerk", so we should move this conversation there.
>
>> Put this information up on the web, along with a RESTful API.
>> Add some command line tools, so that people can add it to the
>> CI tooling.
>
> Even better, yes,


I have tried having this discussion before. We did get a partly working
system which was marginally better than asking copyright@fsf everytime,
but I think it only partly worked, required me to keep manual records of
where requests where and so forth.

Ultimately, anything that we do from here is going to cost time and/or
money either in development or just going through the entire list and
asking everyones permission. For Emacs, development, I am sure it would
be worth it.

Richard, I have cc'd you in. What would be the governance proceedure to
follow to have the FSF investigate and do this work, to make it easier
to check copyright assignment.

Phil

Re: Why are so many great packages not trying to get included in GNU 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. ]]]

  > It should be possible to check automatically whether commits coming in
  > from any git repo are from someone who has assigned copyright. That
  > would, at least, remove the hassle in the case where the papers have
  > been done.

How could that be possible?  How would we know who wrote those
changes?  We can't assume it is the person whose account checked them
in.  Often that is so, but not always.

There may be other issues, such as, if the name on that account is
John Doe, does that mean the user of that account is the same John Doe
that signed an assignment?

It is not terrible lot of work for people to deal with those issues,
but I wouldn't assume a simple program can.


-- 
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: Why are so many great packages not trying to get included in GNU Emacs?

[Stefan Monnier]

> It is not terrible lot of work for people to deal with those issues,
> but I wouldn't assume a simple program can.

The better option is to stop requiring copyright paperwork.
It is harmful to the Emacs project.


        Stefan

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Philippe Vaucher]

> > It is not terrible lot of work for people to deal with those issues,
> > but I wouldn't assume a simple program can.
>
> The better option is to stop requiring copyright paperwork.
> It is harmful to the Emacs project.

Do copyright paperwork really protect Emacs from anything anyway? I
never saw any problems in other open source/free/libre softwares which
didn't do that. It's for sure a big hurdle to new contributors.

(I'm not saying they are useless, I just don't see the point
pragmatically. Don't get upset please, just explain it to me :-)

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Kévin Le Gouguec]

Philippe Vaucher <philippe.vaucher@gmail.com> writes:

>> > It is not terrible lot of work for people to deal with those issues,
>> > but I wouldn't assume a simple program can.
>>
>> The better option is to stop requiring copyright paperwork.
>> It is harmful to the Emacs project.
>
> Do copyright paperwork really protect Emacs from anything anyway? I
> never saw any problems in other open source/free/libre softwares which
> didn't do that. It's for sure a big hurdle to new contributors.

The best assessment of copyright assignment effectiveness I know of is
Bradley Kuhn's recap of the issue in 2012[1]:

> Simply put, the GPL violation defending lawyers have gotten more
> obsessed than ever with delay tactics. They try to raise every
> spurious issue they can think of to delay you, distract you, or
> otherwise try to avoid bringing their client into compliance with the
> terms of GPL.  If you don't hold all the copyrights, they'll focus on
> that issue.  For example, I had an executive of a large computer maker
> tell me that his lawyers say "copyright infringement claims are
> legally invalid unless you hold a majority of the copyrights".  This
> is completely asinine and clearly incorrect in the USA, but violators
> make these arguments all the time.  As another example: I was once
> deposed in a court case for 8 hours about the topic whether or not
> BusyBox's configuration files magically made Erik Andersen's
> copyrights fail to appear in the binary work.  That's a spurious
> argument that I spent 8 hours refuting, yet the violator's lawyer
> again brought it up in the Court as a defense that we had to refute.

To me that sort of suggests that copyright assignment is neither
sufficient (you still need enough resources to overcome "every spurious
issue" the defending lawyers will throw at you) nor necessary (since
Bradley considers it "asinine" to say "an infringement claim is invalid
without holding a majority of the copyrights").

As a layman on these matters (like most potential contributors, I
assume), it would definitely help if the FSF maintained a list[2] of
successful and/or failed GPL enforcement cases *where assignment was a
decisive factor*.  As things stand it's hard to correlate "enforcement
success" with "copyright assignment", so it's really an act of faith we
ask of new contributors…


[1] https://lwn.net/Articles/530239/

[2] Sort of like this FSFE page:
    https://wiki.fsfe.org/Migrated/GPL%20Enforcement%20Cases

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
> Date: Thu, 07 May 2020 11:40:52 +0200
> Cc: Yuan Fu <casouri@gmail.com>, Richard Stallman <rms@gnu.org>,
>  Eric Abrahamsen <eric@ericabrahamsen.net>,
>  Emacs developers <emacs-devel@gnu.org>,
>  Stefan Monnier <monnier@iro.umontreal.ca>,
>  Phillip Lord <phillip.lord@russet.org.uk>, ndame@protonmail.com
> 
> The best assessment of copyright assignment effectiveness I know of is
> Bradley Kuhn's recap of the issue in 2012[1]:
> 
> > Simply put, the GPL violation defending lawyers have gotten more
> > obsessed than ever with delay tactics. They try to raise every
> > spurious issue they can think of to delay you, distract you, or
> > otherwise try to avoid bringing their client into compliance with the
> > terms of GPL.  If you don't hold all the copyrights, they'll focus on
> > that issue.  For example, I had an executive of a large computer maker
> > tell me that his lawyers say "copyright infringement claims are
> > legally invalid unless you hold a majority of the copyrights".  This
> > is completely asinine and clearly incorrect in the USA, but violators
> > make these arguments all the time.  As another example: I was once
> > deposed in a court case for 8 hours about the topic whether or not
> > BusyBox's configuration files magically made Erik Andersen's
> > copyrights fail to appear in the binary work.  That's a spurious
> > argument that I spent 8 hours refuting, yet the violator's lawyer
> > again brought it up in the Court as a defense that we had to refute.
> 
> To me that sort of suggests that copyright assignment is neither
> sufficient (you still need enough resources to overcome "every spurious
> issue" the defending lawyers will throw at you) nor necessary (since
> Bradley considers it "asinine" to say "an infringement claim is invalid
> without holding a majority of the copyrights").

Actually, Bradley's conclusion, the very next paragraph after the one
you quoted, is a direct opposite of yours, AFAICT.  If we are going to
cite others who might have educated opinions on this matter, why not
cite them more completely?

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Kévin Le Gouguec]

Eli Zaretskii <eliz@gnu.org> writes:

>> To me that sort of suggests that copyright assignment is neither
>> sufficient (you still need enough resources to overcome "every spurious
>> issue" the defending lawyers will throw at you) nor necessary (since
>> Bradley considers it "asinine" to say "an infringement claim is invalid
>> without holding a majority of the copyrights").
>
> Actually, Bradley's conclusion, the very next paragraph after the one
> you quoted, is a direct opposite of yours, AFAICT.  

Well, Bradley concludes that assignment makes enforcement "easier":

> But, when I am asked: "Isn't it easier to enforce when you have all
> the copyrights?", my answer has to be: "Yes, it's easier". It's a
> trade-off; there's no question. My personal position is probably
> obvious on this, since I have written often about preferring
> multi-copyright held projects myself, but even I admit to being
> annoyed by the downsides from time to time.

But "easier" is not "directly opposite" to "neither sufficient nor
necessary", at least in my understanding?  Assignment may help, but
Bradley says that it's not strictly necessary legally speaking, and it's
not a silver bullet either.

>                                                     If we are going to
> cite others who might have educated opinions on this matter, why not
> cite them more completely?

In this case, because I did not believe the rest of the quote
contradicted my understanding of the issue, but thank you for
underlining Bradley's conclusion, which of course should be given more
consideration than my own.


The reason why I sent my previous message was in the hope that someone
might give us an updated picture of the enforcement landscape; it's been
some years since 2012.  I apologize if it looked like I was putting
words in Bradley's mouth.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[조성빈]

> 2020. 5. 7. 오후 12:34, Stefan Monnier <monnier@iro.umontreal.ca> 작성:
> 
>> It is not terrible lot of work for people to deal with those issues,
>> but I wouldn't assume a simple program can.
> 
> The better option is to stop requiring copyright paperwork.
> It is harmful to the Emacs project.

Thank you so much for saying this, it’s actively harmful and really the only reason why MELPA is a thing.

>        Stefan

Re: Why are so many great packages not trying to get included in GNU Emacs?

[tomas]

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

On Wed, May 06, 2020 at 11:33:05PM -0400, Stefan Monnier wrote:
> > It is not terrible lot of work for people to deal with those issues,
> > but I wouldn't assume a simple program can.
> 
> The better option is to stop requiring copyright paperwork.
> It is harmful to the Emacs project.

I respectfully disagree.

Cheers
-- t

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

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Stefan Kangas]

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

> The better option is to stop requiring copyright paperwork.
> It is harmful to the Emacs project.

FWIW, I strongly agree.  Thanks for bringing this up.

Best regards,
Stefan Kangas

Re: Why are so many great packages not trying to get included in GNU 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. ]]]

The difficulty about taking precautions,
is that people see the inconvenience of taking them
and may not weigh that against the harm the precautions prevent.

We will continue obtaining copyright assignments
unless we get legal and practical advice that we can stop.

-- 
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: Why are so many great packages not trying to get included in GNU Emacs?

[Stefan Monnier]

> The difficulty about taking precautions, is that people see the
> inconvenience of taking them and may not weigh that against the harm
> the precautions prevent.

It cuts both ways: I think you don't see the second-order harm that
those precautions do beside the obvious first-order effect of having to
ask people to sign paperwork.

Similarly, you don't seem to realize the extent of the chilling effect
of you saying that `s.el` shouldn't be in GNU ELPA.


        Stefan

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Phillip Lord]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> The difficulty about taking precautions,
> is that people see the inconvenience of taking them
> and may not weigh that against the harm the precautions prevent.


Perhaps, but at least be aware of the inconvenience and do all that you
can to lessen the inconvenience.

Provide a way that maintainers can see who has papers, provide a list of
the different emails people use, provide an API so that people can test
for it in their continuous integration, provide a way to track the
progress of the process.

Phil

Re: Why are so many great packages not trying to get included in GNU Emacs?

[João Távora]

On Fri, May 8, 2020 at 7:02 PM Phillip Lord <phillip.lord@russet.org.uk> wrote:
>
> Provide a way that maintainers can see who has papers, provide a list of
> the different emails people use, provide an API so that people can test
> for it in their continuous integration, provide a way to track the
> progress of the process.

I agree that his would be pretty sweet, though I'd be happy just to
have a script to grep the copyright file.  It is my understanding
that as an Emacs committer I have access to a Savannah machine.
Where are the instructions for doing so and accessing the copyright
file?  I think I once had a mail with them, but misplaced it.

João

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Fri, 8 May 2020 19:47:03 +0100
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
> It is my understanding that as an Emacs committer I have access to a
> Savannah machine.  Where are the instructions for doing so and
> accessing the copyright file?  I think I once had a mail with them,
> but misplaced it.

The copyright list is not on Savannah.  You need an account on the GNU
shell server to be able to access it.

Re: Why are so many great packages not trying to get included in GNU 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 need to follow the same policies for including code in GNU ELPA
and the Emacs distribution, because we want the choice of which one
a certain package should go in
to be a purely technical decision.

-- 
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: Why are so many great packages not trying to get included in GNU 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. ]]]

  > Perhaps, but at least be aware of the inconvenience and do all that you
  > can to lessen the inconvenience.

I agree with this goal.  In fact, we have made it considerably less
work, since contributors can now send in the forms digitally.
That takes a lot less time.

I'm in favor in principle of automating the checking, at least
partially.  But we need to carefully study the details.

-- 
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: Why are so many great packages not trying to get included in GNU Emacs?

[Stefan Monnier]

> I'm in favor in principle of automating the checking, at least
> partially.  But we need to carefully study the details.

That's been the status quo for at least ten years.
So, apparently, no, there's no hope for improvement here.


        Stefan

Re: Why are so many great packages not trying to get included in GNU 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. ]]]

  > > I'm in favor in principle of automating the checking, at least
  > > partially.  But we need to carefully study the details.

  > That's been the status quo for at least ten years.
  > So, apparently, no, there's no hope for improvement here.

That seems like a leap of unfaith.

What needs to be checked here is practical -- that it will work
in practice as reliably as our current practice.  This doesn't
require any special knowledge, just careful attention to possible
ways things can go awry, from people who won't overlook problems
in their eagerness to make the change.

-- 
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: Why are so many great packages not trying to get included in GNU Emacs?

[Andreas Röhler]

Am 07.05.20 um 05:33 schrieb Stefan Monnier:
>> It is not terrible lot of work for people to deal with those issues,
>> but I wouldn't assume a simple program can.
> 
> The better option is to stop requiring copyright paperwork.
> It is harmful to the Emacs project.
> 
> 
>          Stefan
> 
> 

Thanks Stefan. Considering that request also vain. Will really someone 
walk to court claiming that all code shipped at a certain moment is 
validly copyright signed? Such a claim would by a major risk.

Andreas

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Clément Pit-Claudel]

On 06/05/2020 22.43, Richard Stallman wrote:
> It is not terrible lot of work for people to deal with those issues, 
> but I wouldn't assume a simple program can.

These days assignments are signed with PGP keys.  Commits can also be signed using PGP keys.  Wouldn't that provide an reliable way to pair up contributors who have assigned copyright with their contributions?

Concretely, the suggestion is that going forward, assign@gnu.org would sign the keys used to sign copyright forms that it receives.  Then contributors would use the same keys to sign patches, and maintainers would just have to query the keyserver to check if the patch author has copyright papers on file.

(The suggestion is not that all Emacs commits should be signed; only that people who don't have commit access but have signed copyright papers could indicate that by signing their commits with the key they used to sign their copyright papers)

Would that not work?

Clément.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Mon, 11 May 2020 14:51:26 -0400
> Cc: eric@ericabrahamsen.net, casouri@gmail.com, emacs-devel@gnu.org,
>  monnier@iro.umontreal.ca, ndame@protonmail.com
> 
> On 06/05/2020 22.43, Richard Stallman wrote:
> > It is not terrible lot of work for people to deal with those issues, 
> > but I wouldn't assume a simple program can.
> 
> These days assignments are signed with PGP keys.  Commits can also be signed using PGP keys.  Wouldn't that provide an reliable way to pair up contributors who have assigned copyright with their contributions?

I think you are missing the main point.  The problem is not security,
it is correct attribution.  The author of the committed changeset (not
the person who does the commit, the author) must be the person who
actually wrote the code, not someone else.  If that someone else is a
real benevolent person, it is still a problem, because we will make a
false presentation that a different person made the change.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Clément Pit-Claudel]

On 11/05/2020 14.57, Eli Zaretskii wrote:>> From: Clément Pit-Claudel <cpitclaudel@gmail.com> Date: Mon, 11 May
>> 2020 14:51:26 -0400 Cc: eric@ericabrahamsen.net, casouri@gmail.com,
>> emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>> ndame@protonmail.com
>> 
>> On 06/05/2020 22.43, Richard Stallman wrote:
>>> It is not terrible lot of work for people to deal with those
>>> issues, but I wouldn't assume a simple program can.
>> 
>> These days assignments are signed with PGP keys.  Commits can also
>> be signed using PGP keys.  Wouldn't that provide an reliable way to
>> pair up contributors who have assigned copyright with their
>> contributions?
> 
> I think you are missing the main point.  The problem is not
> security, it is correct attribution.

Sorry, it seems my email was unclear.  The proposal doesn't have to do with security.  I'm trying to find a robust way to figure out if someone has copyright papers.  Right now Stefan & you can check the list, and the rest of us can't, which is a problem for package maintainers.  Apparently the list can't be made public, so I'm suggesting to make public a list of public keys public instead.  I was not thinking about security.

> The author of the committed changeset (not the person who does the
> commit, the author) must be the person who actually wrote the code,
> not someone else. If that someone else is a real benevolent person, it is still a
> problem, because we will make a false presentation that a different
> person made the change.

That problem exists regardless of how we check whether someone has copyright papers, right?
What I'm trying to find is a way to check whether I can accept a patch into an ELPA package without having to email an Emacs maintainer every time.

Clément.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eric Abrahamsen]

The following message is a courtesy copy of an article
that has been posted to gmane.emacs.devel as well.

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

> On 11/05/2020 14.57, Eli Zaretskii wrote:>> From: Clément Pit-Claudel
> <cpitclaudel@gmail.com> Date: Mon, 11 May
>>> 2020 14:51:26 -0400 Cc: eric@ericabrahamsen.net, casouri@gmail.com,
>>> emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>>> ndame@protonmail.com
>>> 
>>> On 06/05/2020 22.43, Richard Stallman wrote:
>>>> It is not terrible lot of work for people to deal with those
>>>> issues, but I wouldn't assume a simple program can.
>>> 
>>> These days assignments are signed with PGP keys.  Commits can also
>>> be signed using PGP keys.  Wouldn't that provide an reliable way to
>>> pair up contributors who have assigned copyright with their
>>> contributions?
>> 
>> I think you are missing the main point.  The problem is not
>> security, it is correct attribution.
>
> Sorry, it seems my email was unclear. The proposal doesn't have to do
> with security. I'm trying to find a robust way to figure out if
> someone has copyright papers. Right now Stefan & you can check the
> list, and the rest of us can't, which is a problem for package
> maintainers. Apparently the list can't be made public, so I'm
> suggesting to make public a list of public keys public instead. I was
> not thinking about security.
>
>> The author of the committed changeset (not the person who does the
>> commit, the author) must be the person who actually wrote the code,
>> not someone else. If that someone else is a real benevolent person, it is still a
>> problem, because we will make a false presentation that a different
>> person made the change.
>
> That problem exists regardless of how we check whether someone has
> copyright papers, right?
> What I'm trying to find is a way to check whether I can accept a patch
> into an ELPA package without having to email an Emacs maintainer every
> time.

This is above my paygrade but I'm still on the cc, so... If the
information needs to stay private because it contains PII that
contributors haven't consented to release, would it be possible to set
up something automatic where package maintainers enter an email address,
and the system gives us a plain thumbs up or thumbs down? A webform, an
API endpoint, an automated email address, even something built into
debbugs...?

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> Cc: rms@gnu.org, phillip.lord@russet.org.uk, eric@ericabrahamsen.net,
>  casouri@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>  ndame@protonmail.com
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Mon, 11 May 2020 15:13:23 -0400
> 
> > I think you are missing the main point.  The problem is not
> > security, it is correct attribution.
> 
> Sorry, it seems my email was unclear.  The proposal doesn't have to do with security.  I'm trying to find a robust way to figure out if someone has copyright papers.

But that isn't the main problem.  The main problem is how to identify
the name of the person for whom you need to check the status of
copyright assignment.  We are talking about the situation where all
you have is a commit made by someone in a Git repository other than
that of Emacs.  It has some name and some email.  That's all you have.

> That problem exists regardless of how we check whether someone has copyright papers, right?

Yes, but if a human does the checking, that human can do stuff that
programs cannot.

> What I'm trying to find is a way to check whether I can accept a patch into an ELPA package without having to email an Emacs maintainer every time.

Yes, I understand.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Clément Pit-Claudel]

On 11/05/2020 15.27, Eli Zaretskii wrote:
>> Cc: rms@gnu.org, phillip.lord@russet.org.uk, eric@ericabrahamsen.net,
>>  casouri@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>>  ndame@protonmail.com
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Mon, 11 May 2020 15:13:23 -0400
>>
>>> I think you are missing the main point.  The problem is not
>>> security, it is correct attribution.
>>
>> Sorry, it seems my email was unclear.  The proposal doesn't have to do with security.  I'm trying to find a robust way to figure out if someone has copyright papers.
> 
> But that isn't the main problem.  The main problem is how to identify
> the name of the person for whom you need to check the status of
> copyright assignment.  We are talking about the situation where all
> you have is a commit made by someone in a Git repository other than
> that of Emacs.  It has some name and some email. 

No, my situation is that I have someone sending me a pull request or a patch by email.  I can ask this person if they have an assignment, but I can't check whether they in fact do.
I'm proposing a way to fix the problem for future assignments and commits: if the convention is that patches should be signed by their author, it's easy to check if a patch has a corresponding assignment, using the signature.

> We are talking about the situation where all
> you have is a commit made by someone in a Git repository other than
> that of Emacs.

I don't understand this part.  If there is no signature on that commit, how does it relate to the scheme I was proposing?

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> Cc: rms@gnu.org, phillip.lord@russet.org.uk, eric@ericabrahamsen.net,
>  casouri@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>  ndame@protonmail.com
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Mon, 11 May 2020 15:36:31 -0400
> 
> No, my situation is that I have someone sending me a pull request or a patch by email.  I can ask this person if they have an assignment, but I can't check whether they in fact do.

Then you describing a situation different from the one that started
this.  This thread is about copyright assignments for GNU ELPA, where
we discuss packages that already exist on some site that we consider
for adding to ELPA.

> > We are talking about the situation where all
> > you have is a commit made by someone in a Git repository other than
> > that of Emacs.
> 
> I don't understand this part.  If there is no signature on that commit, how does it relate to the scheme I was proposing?

It relates to the subject of this thread, whereas you are talking
about something very different.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Clément Pit-Claudel]

On 11/05/2020 22.23, Eli Zaretskii wrote:
>> Cc: rms@gnu.org, phillip.lord@russet.org.uk, eric@ericabrahamsen.net,
>>  casouri@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>>  ndame@protonmail.com
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Mon, 11 May 2020 15:36:31 -0400
>>
>> No, my situation is that I have someone sending me a pull request or a patch by email.  I can ask this person if they have an assignment, but I can't check whether they in fact do.
> 
> Then you describing a situation different from the one that started
> this.  This thread is about copyright assignments for GNU ELPA, where
> we discuss packages that already exist on some site that we consider
> for adding to ELPA.
Sorry, I did think it was related.  If I start signing all my future commits to Emacs packages outside of Emacs & ELPA with a key that FSF knows about, then won't that mean there won't be a problem with these commits when/if the corresponding packages consider moving into ELPA?

>>> We are talking about the situation where all
>>> you have is a commit made by someone in a Git repository other than
>>> that of Emacs.
>>
>> I don't understand this part.  If there is no signature on that commit, how does it relate to the scheme I was proposing?
> 
> It relates to the subject of this thread, whereas you are talking
> about something very different.

Part of the answer to "Why are so many packages not trying to get included in GNU Emacs?" is that, at least for me, I have no idea how to track whether people have assignments on file, so I don't put my packages in ELPA.  If there was an easy way to check, I would.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> Cc: rms@gnu.org, phillip.lord@russet.org.uk, eric@ericabrahamsen.net,
>  casouri@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>  ndame@protonmail.com
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Mon, 11 May 2020 22:46:23 -0400
> 
> > Then you describing a situation different from the one that started
> > this.  This thread is about copyright assignments for GNU ELPA, where
> > we discuss packages that already exist on some site that we consider
> > for adding to ELPA.
> Sorry, I did think it was related.  If I start signing all my future commits to Emacs packages outside of Emacs & ELPA with a key that FSF knows about, then won't that mean there won't be a problem with these commits when/if the corresponding packages consider moving into ELPA?

For a single package with a single committer who is also the author,
perhaps that would work (assuming the FSF staff arranges for the
copyright list to be accessible via some URL in a secure and
privacy-respecting way).  But the question which started this was much
more general: it asked why do we need to request assignments at all,
if we can determine mechanically, at some future point in time, that
the author of every commit has signed the papers.  That is a much more
general and potentially complicated situation than what you describe.

Besides, if you make that test and discover one or more commits by
people without an assignment, what do you do then?  Those commits
could be years in the past, and the persons who made them could be
hard to find and ask to sign the papers.

> Part of the answer to "Why are so many packages not trying to get included in GNU Emacs?" is that, at least for me, I have no idea how to track whether people have assignments on file, so I don't put my packages in ELPA.  If there was an easy way to check, I would.

I think there was an agreement that providing a public API for
checking this would be good.  But "Someone" needs to do that, and even
after that not every situation could be resolved mechanically,
certainly not at "git commit" time.  A human should be in the loop.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Clément Pit-Claudel]

On 12/05/2020 10.53, Eli Zaretskii wrote:
> I think there was an agreement that providing a public API for
> checking this would be good.  But "Someone" needs to do that, and even
> after that not every situation could be resolved mechanically,
> certainly not at "git commit" time.  A human should be in the loop.

My proposal is that this API should be the FSF signing public keys

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> Cc: rms@gnu.org, phillip.lord@russet.org.uk, eric@ericabrahamsen.net,
>  casouri@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>  ndame@protonmail.com
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Tue, 12 May 2020 12:44:40 -0400
> 
> On 12/05/2020 10.53, Eli Zaretskii wrote:
> > I think there was an agreement that providing a public API for
> > checking this would be good.  But "Someone" needs to do that, and even
> > after that not every situation could be resolved mechanically,
> > certainly not at "git commit" time.  A human should be in the loop.
> 
> My proposal is that this API should be the FSF signing public keys

I don't think I follow.  FSF is not a piece of software and not an
API.  It is an organization.  How can an organization be an API?

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Clément Pit-Claudel]

On 12/05/2020 13.15, Eli Zaretskii wrote:
>> Cc: rms@gnu.org, phillip.lord@russet.org.uk, eric@ericabrahamsen.net,
>>  casouri@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>>  ndame@protonmail.com
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Tue, 12 May 2020 12:44:40 -0400
>>
>> On 12/05/2020 10.53, Eli Zaretskii wrote:
>>> I think there was an agreement that providing a public API for
>>> checking this would be good.  But "Someone" needs to do that, and even
>>> after that not every situation could be resolved mechanically,
>>> certainly not at "git commit" time.  A human should be in the loop.
>>
>> My proposal is that this API should be the FSF signing public keys
> 
> I don't think I follow.  FSF is not a piece of software and not an
> API.  It is an organization.  How can an organization be an API?

With the scheme I propose, you don't need an API any more, I think (for properly signed commits).
You still have the same problem for old commits, of course.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> Cc: rms@gnu.org, phillip.lord@russet.org.uk, eric@ericabrahamsen.net,
>  casouri@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>  ndame@protonmail.com
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Tue, 12 May 2020 13:26:37 -0400
> 
> >> My proposal is that this API should be the FSF signing public keys
> > 
> > I don't think I follow.  FSF is not a piece of software and not an
> > API.  It is an organization.  How can an organization be an API?
> 
> With the scheme I propose, you don't need an API any more, I think (for properly signed commits).

Now I'm completely confused: what scheme are you proposing?  Can you
describe it in more detail?

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Clément Pit-Claudel]

On 12/05/2020 13.39, Eli Zaretskii wrote:
>> Cc: rms@gnu.org, phillip.lord@russet.org.uk,
>> eric@ericabrahamsen.net, casouri@gmail.com, emacs-devel@gnu.org,
>> monnier@iro.umontreal.ca, ndame@protonmail.com From: Clément
>> Pit-Claudel <cpitclaudel@gmail.com> Date: Tue, 12 May 2020 13:26:37
>> -0400
>> 
>>>> My proposal is that this API should be the FSF signing public
>>>> keys
>>> 
>>> I don't think I follow.  FSF is not a piece of software and not
>>> an API.  It is an organization.  How can an organization be an
>>> API?
>> 
>> With the scheme I propose, you don't need an API any more, I think
>> (for properly signed commits).
> 
> Now I'm completely confused: what scheme are you proposing?  Can you 
> describe it in more detail?

Yes, of course.

One problem with have when integrating external packages is that we have many commits whose copyright status is unclear: who wrote them? Does the FSF have a copyright assignment for that person?

Currently, the way you answer such a question is that you look at the commit, try to determine the author, and check a list of people who have assigned copyright to see if the author is in it.

This process is cumbersome, because few have access to the list.  One way to make it smoother is to add an API that gives access to that list.  

Another strategy, which doesn't solve the problem for past commits but could help for future commits, is to embed that information into commits.  Something like adding a line in the commit saying "I-have-assigned-copyright: Yes".

Of course, just adding that line doesn't prove anything: we want to make sure that we do have an assignment for that commit.
So, instead of adding a line, the author could sign the commit with their PGP key, saying "all these changes are mine or from sources owned by FSF" (a bit like a developer certificate of origin).

Now the problem is reduced to "does the author with this PGP key have an assignment on file"?  But this question can be answered in a decentralized way (no need for an API): the FSF can just sign keys instead.

Indeed, currently, when you assign copyright to the FSF, you sign a document with a GPG key.  The FSF could sign that key to indicate "we have received copyright papers for this author".

Then, to verify "do we have papers for the author of this commit", anyone could check "is this commit signed with a key signed by the FSF"?

As a package maintainer, I wouldn't have to ever check fencepost to verify assignments when I receive patches.  Instead, the way I check that someone has an assignment on file is by asking them to sign their commit with an FSF-signed key.

Does it make sense?
Clément.  

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Alan Third]

On Tue, May 12, 2020 at 03:48:01PM -0400, Clément Pit-Claudel wrote:
> Now the problem is reduced to "does the author with this PGP key
> have an assignment on file"? But this question can be answered in a
> decentralized way (no need for an API): the FSF can just sign keys
> instead.

As if there aren’t enough people complaining about copyright
assignment, now you want to force everyone to use the horror that is
PGP/GPG?

Good luck.
-- 
Alan Third

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Clément Pit-Claudel]

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

On 12/05/2020 16.17, Alan Third wrote:
> On Tue, May 12, 2020 at 03:48:01PM -0400, Clément Pit-Claudel wrote:
>> Now the problem is reduced to "does the author with this PGP key
>> have an assignment on file"? But this question can be answered in a
>> decentralized way (no need for an API): the FSF can just sign keys
>> instead.
> 
> As if there aren’t enough people complaining about copyright
> assignment, now you want to force everyone to use the horror that is
> PGP/GPG?

No no, not at all!  Definitely not force and definitely not everyone.  I'm trying to find a way to allow package maintainers to check copyright assignments when they accept patches, that's all.  There are easy cases: for Emacs committers like you, the list is already public, so that's no trouble (and thus signatures wouldn't be needed).  For others, the signature would be one reliable option to determine whether they have papers on file.

But the complexity of PGP is a valid concern.  I operated under the assumption that most new contributors sign copyright papers with PGP, and so that PGP was a reasonable baseline.

Concretely, how do you handle these cases?  What am I supposed to do, when I get a patch, to check if the patch author has an assignment on file?  Surely I can't bother Eli every time.  Is it enough to take the author's word for it that they have an assignment?  Alan, do you have advice on handling these situations?

As an alternative, the attached python script implements a REST API to do the checking.  I don't have access to fencepost, so I don't know what format the file tracking assignments is — I made a guess about that part.  

(Of course, having an API makes it possible to determine whether a given email address has copyright papers on file, but it gives no guarantees against impersonation.)

Cheers,
Clément.

[-- Attachment #2: fencepost_api.py --]
[-- Type: text/x-python, Size: 628 bytes --]

#!/usr/bin/env python3
from flask import Flask

# Usage: pip3 install flask
#        echo "user@domain some more data" > /tmp/assignments
#        FLASK_APP=fencepost_api.py flask run
#        firefox http://127.0.0.1:5000/has_assignment/name@domain57.org

app = Flask(__name__)

ASSIGNMENTS_FILE = "/tmp/assignments"

def get_copyright_list():
    with open(ASSIGNMENTS_FILE) as assignments:
        for line in assignments:
            yield line.split()[0].lower()

@app.route('/has_assignment/<email_address>')
def check_assignment(email_address):
    return "yes" if email_address.lower() in get_copyright_list() else "no"

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Tue, 12 May 2020 23:03:06 -0400
> 
> Surely I can't bother Eli every time.

Yes, you can.  It isn't a bother.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Alan Third]

On Tue, May 12, 2020 at 11:03:06PM -0400, Clément Pit-Claudel wrote:
> 
> But the complexity of PGP is a valid concern. I operated under the
> assumption that most new contributors sign copyright papers with
> PGP, and so that PGP was a reasonable baseline.

I didn’t sign mine with PGP, as far as I can remember, so my
assumption was that most people don’t. Is it a new requirement?

If people are happy to sign commits with PGP then I don’t have a
problem with that, I just really don’t want to be left having to try
to talk someone through the process of setting it up.

> Concretely, how do you handle these cases? What am I supposed to do,
> when I get a patch, to check if the patch author has an assignment
> on file? Surely I can't bother Eli every time. Is it enough to take
> the author's word for it that they have an assignment? Alan, do you
> have advice on handling these situations?

I’m afraid not. Usually I check the Emacs repo to see if they’re
already in it, if not then I ask if they’ve signed the papers, and
usually Eli pops up with the answer before they reply.

> As an alternative, the attached python script implements a REST API
> to do the checking. I don't have access to fencepost, so I don't
> know what format the file tracking assignments is — I made a guess
> about that part.

I think an API makes a lot of sense.
-- 
Alan Third

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Clément Pit-Claudel]

On 13/05/2020 12.58, Alan Third wrote:
> On Tue, May 12, 2020 at 11:03:06PM -0400, Clément Pit-Claudel wrote:
>>
>> But the complexity of PGP is a valid concern. I operated under the
>> assumption that most new contributors sign copyright papers with
>> PGP, and so that PGP was a reasonable baseline.
> 
> I didn’t sign mine with PGP, as far as I can remember, so my
> assumption was that most people don’t. Is it a new requirement?

It's not a new requirement, just a new option, I think :) (well, not so new: I did mine in 2014 with PGP).

>> Alan, do you
>> have advice on handling these situations?
> 
> I’m afraid not. Usually I check the Emacs repo to see if they’re
> already in it, if not then I ask if they’ve signed the papers, and
> usually Eli pops up with the answer before they reply.

OK, thanks a lot.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Robert Pluim]

>>>>> On Wed, 13 May 2020 13:36:08 -0400, Clément Pit-Claudel <cpitclaudel@gmail.com> said:

    Clément> On 13/05/2020 12.58, Alan Third wrote:
    >> On Tue, May 12, 2020 at 11:03:06PM -0400, Clément Pit-Claudel wrote:
    >>> 
    >>> But the complexity of PGP is a valid concern. I operated under the
    >>> assumption that most new contributors sign copyright papers with
    >>> PGP, and so that PGP was a reasonable baseline.
    >> 
    >> I didn’t sign mine with PGP, as far as I can remember, so my
    >> assumption was that most people don’t. Is it a new requirement?

    Clément> It's not a new requirement, just a new option, I think :)
    Clément> (well, not so new: I did mine in 2014 with PGP).

I did mine in 2017 via print/sign/scan, I guess it depends on where
you reside. There are other options these days, but weʼd have to find
an acceptable ESIGN/eIDAS provider to use.

Robert

Re: Why are so many great packages not trying to get included in GNU 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. ]]]

  > I didn’t sign mine with PGP, as far as I can remember, so my
  > assumption was that most people don’t. Is it a new requirement?

I think it is a new option.  Some years ago we needed a signature on paper,
but then we became able to accept digital signatures.  I think we use
GPG to implement 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: Why are so many great packages not trying to get included in GNU 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. ]]]

  > I’m afraid not. Usually I check the Emacs repo to see if they’re
  > already in it,

In concrete terms, what does "already in it" mean?
We can install small changes without papers, so the fact that a person's
name is on a change is not proof that we got an assignment from per.

-- 
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: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Thu, 14 May 2020 01:08:33 -0400
> Cc: casouri@gmail.com, eric@ericabrahamsen.net, alan@idiocy.org,
>  emacs-devel@gnu.org, cpitclaudel@gmail.com, monnier@iro.umontreal.ca,
>  eliz@gnu.org, phillip.lord@russet.org.uk, ndame@protonmail.com
> 
> We can install small changes without papers, so the fact that a person's
> name is on a change is not proof that we got an assignment from per.

Normally such commits should have a telltale header in the log message
saying this was accepted without papers.  Of course, sometimes people
(including myself) forget, and Git doesn't allow amending commit log
messages post-factum, so the error stays there forever.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Alan Third]

On Thu, May 14, 2020 at 05:09:26PM +0300, Eli Zaretskii wrote:
> > From: Richard Stallman <rms@gnu.org>
> > Date: Thu, 14 May 2020 01:08:33 -0400
> > Cc: casouri@gmail.com, eric@ericabrahamsen.net, alan@idiocy.org,
> >  emacs-devel@gnu.org, cpitclaudel@gmail.com, monnier@iro.umontreal.ca,
> >  eliz@gnu.org, phillip.lord@russet.org.uk, ndame@protonmail.com
> > 
> > We can install small changes without papers, so the fact that a person's
> > name is on a change is not proof that we got an assignment from per.
> 
> Normally such commits should have a telltale header in the log message
> saying this was accepted without papers.  Of course, sometimes people
> (including myself) forget, and Git doesn't allow amending commit log
> messages post-factum, so the error stays there forever.

Yes, I wouldn’t commit a change on the strength of a small number of
short commits, but if they had a few large commits I’d have to assume
they’re good.

-- 
Alan Third

Re: Why are so many great packages not trying to get included in GNU 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. ]]]

Emacs has a convenient interface to GPG.  I think it is epg.
Please try it.

Our policy is that it is good to recommend people use another GNU
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: Why are so many great packages not trying to get included in GNU Emacs?

[Dmitry Gutov]

On 12.05.2020 22:48, Clément Pit-Claudel wrote:
> So, instead of adding a line, the author could sign the commit with their PGP key, saying "all these changes are mine or from sources owned by FSF" (a bit like a developer certificate of origin).

Considering that signed commits are not ubiquitous, it seems to be not a 
trivial thing to do. Also, we'd need some recourse in case when some 
commits have slipped by that are not signed anyway. Or are signed by a 
key that Savannah doesn't know about (or whatever other database we'd be 
using).

I was suggesting to sign tagged commits (for example), which seems more 
feasible, but keeps the responsibility of checking the copyright status 
on the author. The the reasons to do that would be different (basically, 
security).

Re: Why are so many great packages not trying to get included in GNU 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. ]]]

  > Currently, the way you answer such a question is that you look at
  > the commit, try to determine the author, and check a list of
  > people who have assigned copyright to see if the author is in it.

  > This process is cumbersome, because few have access to the list.
  > One way to make it smoother is to add an API that gives access to
  > that list.

I would like to make that easier.  That may be complex.  We don't
publish the list, for privacy reasons.  We don't want to offer
the public a way to probe the list.  We can offer certain people
access to probe the list in limited ways.  We need to discuss that
with the FSF.

  > Indeed, currently, when you assign copyright to the FSF, you sign
  > a document with a GPG key.  The FSF could sign that key to
  > indicate "we have received copyright papers for this author".

  > Then, to verify "do we have papers for the author of this commit",
  > anyone could check "is this commit signed with a key signed by the
  > FSF"?

At first glance, this looks good to me.  It would be necessary
for people to study it to make sure it doens't have problems.

-- 
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: Why are so many great packages not trying to get included in GNU Emacs?

[Clément Pit-Claudel]

On 13/05/2020 00.07, Richard Stallman wrote:
>   > Currently, the way you answer such a question is that you look at
>   > the commit, try to determine the author, and check a list of
>   > people who have assigned copyright to see if the author is in it.
> 
>   > This process is cumbersome, because few have access to the list.
>   > One way to make it smoother is to add an API that gives access to
>   > that list.
> 
> I would like to make that easier.  

Thanks a lot.  It would be great.

> That may be complex.  We don't
> publish the list, for privacy reasons.  We don't want to offer
> the public a way to probe the list.  

Maybe we can publicize a part of the list which would not violate privacy?  When I signed my copyright papers, I answered yes to a question that said "Would it be acceptable for us to publicize your contribution by microblogging that you are contributing, and listing your name in our monthly newsletter?".  I think it is safe to assume that those who answered yes to this question do not object to appearing on a public list; correct?

>   > Indeed, currently, when you assign copyright to the FSF, you sign
>   > a document with a GPG key.  The FSF could sign that key to
>   > indicate "we have received copyright papers for this author".
> 
>   > Then, to verify "do we have papers for the author of this commit",
>   > anyone could check "is this commit signed with a key signed by the
>   > FSF"?
> 
> At first glance, this looks good to me.  It would be necessary
> for people to study it to make sure it doens't have problems.

Note that with this scheme, it would be possible to reconstruct parts of the list, by looking for keys signed by the FSF.  So, if knowing a list of address emails that have signed FSF copyright papers is an issue, then this scheme won't solve it.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> Cc: eliz@gnu.org, casouri@gmail.com, eric@ericabrahamsen.net,
>  emacs-devel@gnu.org, monnier@iro.umontreal.ca, ndame@protonmail.com,
>  phillip.lord@russet.org.uk
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Wed, 13 May 2020 00:22:56 -0400
> 
> Maybe we can publicize a part of the list which would not violate privacy?  When I signed my copyright papers, I answered yes to a question that said "Would it be acceptable for us to publicize your contribution by microblogging that you are contributing, and listing your name in our monthly newsletter?".  I think it is safe to assume that those who answered yes to this question do not object to appearing on a public list; correct?

If you suggest making public a part of the entries in the list, then
this would be worse than not publishing it at all, I think.

If you suggest publishing part of the _data_ in each entry, then this
should work in principle, but (a) "Someone" needs to do the work of
setting this up, and (b) even in this case there might be issues which
need to be resolved.  For example, some people need to submit
disclaimers from their employers, in addition to their personal
assignment, but publishing that part discloses their employment, which
may be invading their privacy.  Others have other private arrangements
mentioned, or are minors who need their parents' permissions, etc.
Deciding which of this is necessary to make sure a person's assignment
is in order, while at the same time avoiding disclosure of private
information is the hard part of the job.  At least AFAIU, that is.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Clément Pit-Claudel]

On 13/05/2020 11.00, Eli Zaretskii wrote:
>> Cc: eliz@gnu.org, casouri@gmail.com, eric@ericabrahamsen.net,
>>  emacs-devel@gnu.org, monnier@iro.umontreal.ca, ndame@protonmail.com,
>>  phillip.lord@russet.org.uk
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Wed, 13 May 2020 00:22:56 -0400
>>
>> Maybe we can publicize a part of the list which would not violate privacy?  When I signed my copyright papers, I answered yes to a question that said "Would it be acceptable for us to publicize your contribution by microblogging that you are contributing, and listing your name in our monthly newsletter?".  I think it is safe to assume that those who answered yes to this question do not object to appearing on a public list; correct?
> 
> If you suggest making public a part of the entries in the list, then
> this would be worse than not publishing it at all, I think.
> 
> If you suggest publishing part of the _data_ in each entry, then this
> should work in principle, but (a) "Someone" needs to do the work of
> setting this up

I've sent an implementation ^^ I'm happy to write the code if code is needed, it's the specs that I don't know :)

> and (b) even in this case there might be issues which
> need to be resolved.  For example, some people need to submit
> disclaimers from their employers, in addition to their personal
> assignment, but publishing that part discloses their employment, which
> may be invading their privacy.

I think an API could say "yes", "no", or "check with maintainer".
We can put all tricky cases in the "check with maintainer" category.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> Cc: rms@gnu.org, casouri@gmail.com, eric@ericabrahamsen.net,
>  emacs-devel@gnu.org, monnier@iro.umontreal.ca, ndame@protonmail.com,
>  phillip.lord@russet.org.uk
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Wed, 13 May 2020 11:16:50 -0400
> 
> > If you suggest publishing part of the _data_ in each entry, then this
> > should work in principle, but (a) "Someone" needs to do the work of
> > setting this up
> 
> I've sent an implementation ^^ I'm happy to write the code if code is needed, it's the specs that I don't know :)

I meant to set this up on gnu.org machines.  The hard part is to
extract the data that can be published, I think (and maybe even to
decide which part is that).

> > and (b) even in this case there might be issues which
> > need to be resolved.  For example, some people need to submit
> > disclaimers from their employers, in addition to their personal
> > assignment, but publishing that part discloses their employment, which
> > may be invading their privacy.
> 
> I think an API could say "yes", "no", or "check with maintainer".
> We can put all tricky cases in the "check with maintainer" category.

Anything's possible, but a volunteer who'd do all that is still
needed.  As always with Emacs (and GNU in general).

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Clément Pit-Claudel]

On 13/05/2020 12.01, Eli Zaretskii wrote:
>> Cc: rms@gnu.org, casouri@gmail.com, eric@ericabrahamsen.net,
>>  emacs-devel@gnu.org, monnier@iro.umontreal.ca, ndame@protonmail.com,
>>  phillip.lord@russet.org.uk
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Wed, 13 May 2020 11:16:50 -0400
>>
>>> If you suggest publishing part of the _data_ in each entry, then this
>>> should work in principle, but (a) "Someone" needs to do the work of
>>> setting this up
>>
>> I've sent an implementation ^^ I'm happy to write the code if code is needed, it's the specs that I don't know :)
> 
> I meant to set this up on gnu.org machines.  The hard part is to
> extract the data that can be published, I think (and maybe even to
> decide which part is that).
>
> Anything's possible, but a volunteer who'd do all that is still
> needed.  As always with Emacs (and GNU in general).

Yes, of course: again, I'm happy to write the code and set thip up on gnu.org machines, if someone can clarify which data can be exposed.
But in another thread Noam was suggesting that it's enough to just ask the contributor whether they have an assignment, so maybe this is all moot for future commits?

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Alfred M. Szmidt]

Please do not forget that the FSF is the responsible party for the
copyright list.

Re: Why are so many great packages not trying to get included in GNU 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. ]]]

  > Maybe we can publicize a part of the list which would not violate
  > privacy?  When I signed my copyright papers, I answered yes to a
  > question that said "Would it be acceptable for us to publicize
  > your contribution by microblogging that you are contributing, and
  > listing your name in our monthly newsletter?".  I think it is safe
  > to assume that those who answered yes to this question do not
  > object to appearing on a public list; correct?

I think so.  However, we probably didn't ask that question N years ago.

Hmm.  If the name of the contributor will appear publicly in the repo,
I guess privacy about the name is not necessary.  Maybe it is only the
_other_ data in that file which we need to keep private.  If so, this
could be easy to solve.

Eli, would you like to talk about this with people at the FSF?


-- 
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: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: casouri@gmail.com, eric@ericabrahamsen.net, emacs-devel@gnu.org,
> 	monnier@iro.umontreal.ca, eliz@gnu.org,
> 	phillip.lord@russet.org.uk, ndame@protonmail.com
> Date: Thu, 14 May 2020 01:09:05 -0400
> 
> Hmm.  If the name of the contributor will appear publicly in the repo,
> I guess privacy about the name is not necessary.  Maybe it is only the
> _other_ data in that file which we need to keep private.  If so, this
> could be easy to solve.
> 
> Eli, would you like to talk about this with people at the FSF?

I could, but I don't think I know anything about this any other GNU
maintainers don't.

Whom should we talk to, and what should we say?  Setting up such a
service would need savannah-hackers or sysadmin@gnu.org to do
something, I guess, and the FSF people are not them?

Re: Why are so many great packages not trying to get included in GNU 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. ]]]

  > Whom should we talk to, and what should we say?  Setting up such a
  > service would need savannah-hackers or sysadmin@gnu.org to do
  > something, I guess, and the FSF people are not them?

Sysadmin would have to implement it, but the copyright team would
first decide what is ok to do.

I will ask them now.

-- 
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: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> Cc: rms@gnu.org, phillip.lord@russet.org.uk, eric@ericabrahamsen.net,
>  casouri@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>  ndame@protonmail.com
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Tue, 12 May 2020 15:48:01 -0400
> 
> Another strategy, which doesn't solve the problem for past commits but could help for future commits, is to embed that information into commits.  Something like adding a line in the commit saying "I-have-assigned-copyright: Yes".
> 
> Of course, just adding that line doesn't prove anything: we want to make sure that we do have an assignment for that commit.
> So, instead of adding a line, the author could sign the commit with their PGP key, saying "all these changes are mine or from sources owned by FSF" (a bit like a developer certificate of origin).
> 
> Now the problem is reduced to "does the author with this PGP key have an assignment on file"?  But this question can be answered in a decentralized way (no need for an API): the FSF can just sign keys instead.

This will only work for some cases: when the committer is also the
author, and when the committer has a PGP key.  So some cases will
still need to be handled in some other way, and I suspect that those
cases are the majority.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Clément Pit-Claudel]

On 13/05/2020 10.14, Eli Zaretskii wrote:
>> Cc: rms@gnu.org, phillip.lord@russet.org.uk, eric@ericabrahamsen.net,
>>  casouri@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>>  ndame@protonmail.com
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Tue, 12 May 2020 15:48:01 -0400
>>
>> Another strategy, which doesn't solve the problem for past commits but could help for future commits, is to embed that information into commits.  Something like adding a line in the commit saying "I-have-assigned-copyright: Yes".
>>
>> Of course, just adding that line doesn't prove anything: we want to make sure that we do have an assignment for that commit.
>> So, instead of adding a line, the author could sign the commit with their PGP key, saying "all these changes are mine or from sources owned by FSF" (a bit like a developer certificate of origin).
>>
>> Now the problem is reduced to "does the author with this PGP key have an assignment on file"?  But this question can be answered in a decentralized way (no need for an API): the FSF can just sign keys instead.
> 
> This will only work for some cases: when the committer is also the
> author, and when the committer has a PGP key.  So some cases will
> still need to be handled in some other way, and I suspect that those
> cases are the majority.

I have the opposite intuition, but not very much evidence.  I think it depends a lot on how you end up using git, too (in particular, whether patches are typically rebased or marged).
Alan raised the issue of PGP's complexity and availability, and I don't have much to say on that.  But on the committer versus author debate, as long as the original patch sent by the contributor is signed, it might not matter whether the final commit is (as long as the committer also does have papers and record that they checked that commit).

Re: Why are so many great packages not trying to get included in GNU 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. ]]]

  > I think you are missing the main point.  The problem is not security,
  > it is correct attribution.  The author of the committed changeset (not
  > the person who does the commit, the author) must be the person who
  > actually wrote the code, not someone else.  If that someone else is a
  > real benevolent person, it is still a problem, because we will make a
  > false presentation that a different person made the change.

We do our best to avoid errors of this sort, but our current systems
don'tmake errors absolutely impossible.  Can we make Clement's proposal
as reliable as our current non-automated system?  I don't see, off-hand,
why that would be impossible.

-- 
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: Why are so many great packages not trying to get included in GNU 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. ]]]

  > I think it could be even simpler than that: ELPA is built every 24 hours
  > right now. If we just registered external repos with ELPA, part of the
  > build process could be pulling from those repos automatically

That is rather breathless, so I can't concretely understand the
proposal.  I can't start to think about what specific consequences it
might have.  I am not sure which situations you propose to use this
solution for.

If this is meant as a way to implement pull requests, there is no need
for it.  We will not implement pull requests by copying proposed
patches into our repo before they are installed.

There are various ways to implement pull requests.  The way I hope we
will do it is that maintainers can ask to see the contents of the
request, and commit it to our repo if/when that is proper.  Until that
time, the patch won't be in our repo at all.

Or maybe you're proposing a way to make a given package in GNU ELPA
virtually included from some other GNU-managed repository; the method
consisting of copying each commit automatically from that other repo
to the GNU ELPA repo.

It is ok to do that, assuming the other repo is managed appropriately,
and your method could do it.  Other methods could give equivalent
results.  We could use whichever method is most convenient.

The crucial thing is that the repo where the package is really maintained
be managed carefully in regard to who can commit changes.

-- 
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: Why are so many great packages not trying to get included in GNU Emacs?

[Eric Abrahamsen]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > I think it could be even simpler than that: ELPA is built every 24 hours
>   > right now. If we just registered external repos with ELPA, part of the
>   > build process could be pulling from those repos automatically
>
> That is rather breathless, so I can't concretely understand the
> proposal.  I can't start to think about what specific consequences it
> might have.  I am not sure which situations you propose to use this
> solution for.
>
> If this is meant as a way to implement pull requests, there is no need
> for it.  We will not implement pull requests by copying proposed
> patches into our repo before they are installed.
>
> There are various ways to implement pull requests.  The way I hope we
> will do it is that maintainers can ask to see the contents of the
> request, and commit it to our repo if/when that is proper.  Until that
> time, the patch won't be in our repo at all.
>
> Or maybe you're proposing a way to make a given package in GNU ELPA
> virtually included from some other GNU-managed repository; the method
> consisting of copying each commit automatically from that other repo
> to the GNU ELPA repo.

Yes, it's this latter I was referring to -- I don't have much feeling
about pull requests either way.

> It is ok to do that, assuming the other repo is managed appropriately,
> and your method could do it.  Other methods could give equivalent
> results.  We could use whichever method is most convenient.
>
> The crucial thing is that the repo where the package is really maintained
> be managed carefully in regard to who can commit changes.

And this was ultimately Stefan's concern, and the reason why my
suggestion is probably no-go. But no matter!

Re: Why are so many great packages not trying to get included in GNU 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. ]]]

  > > It is ok to do that, assuming the other repo is managed appropriately,
  > > and your method could do it.  Other methods could give equivalent
  > > results.  We could use whichever method is most convenient.
  > >
  > > The crucial thing is that the repo where the package is really maintained
  > > be managed carefully in regard to who can commit changes.

  > And this was ultimately Stefan's concern, and the reason why my
  > suggestion is probably no-go. But no matter!

I think your suggestion has potential.  We could set up the
package's own repo ourselves and manage it in the right way.

-- 
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: Why are so many great packages not trying to get included in GNU Emacs?

[Tim Cross]

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

On Sat, 25 Apr 2020 at 13:32, Richard Stallman <rms@gnu.org> wrote:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
>
> If this is meant as a way to implement pull requests, there is no need
> for it.  We will not implement pull requests by copying proposed
> patches into our repo before they are installed.
>
>
There seems to be some confusion regarding 'pull requests'. When you look
at it, all a pull request is is a request to merge a branch from another
repo into your repo. Nothing is added to your repo until you perform the
merge. The pull request adds nothing to your repo. Some of this confusion
is likely due to github and to some extent, gitlab, putting some UI 'sugar'
on top of the process to make it easier. However, you can do/manage pull
requests completely from the git command line (although it is a bit
fiddly).  Basically, you add the PR repository to your LOCAL repo and check
it out as a branch. Do whatever you need (review, fix, etc), commit it to
your local repository. Perhaps do some diffs against your master repository
and if all is good, merge it with your local master branch. At this point,
there is still no change to the 'main' master repository. If the merge all
goes fine, you can then push the changes to your master branch in your main
repository. It is only at this point that the changes have been introduced
to the main repository.

So, in short, making a PR has NO impact on the master repository until
someone with write permission ie.g. the owner, merges the PR into the
master repository. In this respect, it is no different from when the owner
recieves a patch via email. Others cannot see the PR in the master
repository (they would be able to see it and clone it from the pull
requestor's repository, just like I can pull fro any public repository in
github or gitlab), It is only after the owner (or someone with write
permission to the 'master' repository (i.e. the one on savannah) merges
that PR into the master repo that it will be seen by anyone who has cloned
the master repo.

It should also be noted that the 'git pull-request' command is NOT a
standard git command. This is an extension that github has added. It would
be possible to create an FSF GNU git module which does something similar or
more specific to suit FSF requirements. For example, you could have a
module which looks at the size of the changes in the commit, checks a list
of people who have submitted copyright paperwork and only allow the pull
request to complete if either the change is 'tiny' or the submitter has
provided copyright assignment.

-- 
regards,

Tim

--
Tim Cross

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

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> From: Tim Cross <theophilusx@gmail.com>
> Date: Sat, 25 Apr 2020 17:56:48 +1000
> Cc: Eric Abrahamsen <eric@ericabrahamsen.net>, Yuan Fu <casouri@gmail.com>,
>  ndame <ndame@protonmail.com>, Stefan Monnier <monnier@iro.umontreal.ca>,
>  Emacs developers <emacs-devel@gnu.org>
> 
>  If this is meant as a way to implement pull requests, there is no need
>  for it.  We will not implement pull requests by copying proposed
>  patches into our repo before they are installed.
> 
> There seems to be some confusion regarding 'pull requests'.

There definitely is, but let's not exacerbate the situation by using
confusing inconsistent terminology.

> When you look at it, all a pull request is is a request to merge a
> branch from another repo into your repo.  Nothing is added to your
> repo until you perform the merge.

It should be clear that Richard is talking about 2 things:

  . the location (i.e. the hosting server) where that "other"
    repository lives
  . the process of merging the PR

> Basically, you add
> the PR repository to your LOCAL repo

How can you "add a repository to a repo"?  (And why use two different
words, "repository" and "repo", to indicate the same thing?)  Don't
you mean to say "you fork a repository", i.e. clone the repository to
produce a separate one, in another directory on the local system?

> and check it out as a branch. Do whatever you need (review, fix, etc),
> commit it to your local repository. Perhaps do some diffs against your master repository and if all is good,
> merge it with your local master branch. At this point, there is still no change to the 'main' master repository.
> If the merge all goes fine, you can then push the changes to your master branch in your main repository. It is
> only at this point that the changes have been introduced to the main repository. 
> 
> So, in short, making a PR has NO impact on the master repository until someone with write permission ie.g.
> the owner, merges the PR into the master repository.

And here you use "master repository" without defining what that is,
and then use "main master repository" as if it were a different thing
(is it?).  Should we be surprised that people get confused?

I think there are 3 repositories involved in this story:

  . the upstream repository, which lives on Savannah
  . the local clone of the upstream repository on the user's machine
  . the "forked repository", which is a clone of the clone mentioned
    in the previous item; this forked repository is also local, and it
    is where the user makes the changes which will be the subject of
    the PR

So far so good?

Then we have another person in the picture, someone with write access
to the upstream repository.  That person is supposed to pull from the
"forked repository", into his or her local clone of the upstream,
which merges the PR changes, and then eventually push the results of
the merge to upstream.  At which point the PR is considered "accepted"
(or "merged"), and is visible to everyone who tracks the upstream.

Does this describe what you had in mind?

If so, as previous discussions have established, the issue that is of
concern is what server should host the "forked repository".  It
cannot be someone's private machine, because private machines don't
usually have Git servers, and thus cannot be pulled from.  Richard
also didn't want this to be Savannah, because then the forked
repository and its changes could be perceived as "endorsed" by GNU.
The practical solution is to host this on some nongnu.org server.

And now I think you can understand what Richard means when he says
"our repo".

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Tim Cross]

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

On Sat, 25 Apr 2020 at 18:33, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Tim Cross <theophilusx@gmail.com>
> > Date: Sat, 25 Apr 2020 17:56:48 +1000
> > Cc: Eric Abrahamsen <eric@ericabrahamsen.net>, Yuan Fu <
> casouri@gmail.com>,
> >  ndame <ndame@protonmail.com>, Stefan Monnier <monnier@iro.umontreal.ca
> >,
> >  Emacs developers <emacs-devel@gnu.org>
> >
> >  If this is meant as a way to implement pull requests, there is no need
> >  for it.  We will not implement pull requests by copying proposed
> >  patches into our repo before they are installed.
> >
> > There seems to be some confusion regarding 'pull requests'.
>
> There definitely is, but let's not exacerbate the situation by using
> confusing inconsistent terminology.
>
> > When you look at it, all a pull request is is a request to merge a
> > branch from another repo into your repo.  Nothing is added to your
> > repo until you perform the merge.
>
> It should be clear that Richard is talking about 2 things:
>
>   . the location (i.e. the hosting server) where that "other"
>     repository lives
>   . the process of merging the PR
>
>
No, it is not clear. What I got from a number of Richard's posts was the
concern that a PR would appear to be part of the GNU Emacs distribution or
in some way mistaken as being 'official' or agreed to. What I was trying to
make clear is that the PR has NO impact on the repository in itself. It is
only after someone takes that pull request and merges it into the
repository that it becomes part of the repository. A PR in itself is just a
request to merge changes. It is effectively no different from sending an
email with a patch in it except it is more public (or at least can be). As
the PR is hosted in a completely separate repository, there is no chance it
can be confused or seen as being part of the official repository.


> > Basically, you add
> > the PR repository to your LOCAL repo
>
> How can you "add a repository to a repo"?  (And why use two different
> words, "repository" and "repo", to indicate the same thing?)


repo is shorthand for repository. It is a term in common usage and I think
pretty obvious.


> Don't
> you mean to say "you fork a repository", i.e. clone the repository to
> produce a separate one, in another directory on the local system?
>
>
Definitely not! You do not need to clone the PR repository. You can add the
PR repository to your local clone as another upstream source. This is part
of what makes PRs so easy to work with. Once you have aded the PR
repository to your clone, you can checkout a branch from that repo in your
clone. From this point, merging is just normal merging of branches in your
clone. Nothing is seen in the upstream repo until you do a push.


> and check it out as a branch. Do whatever you need (review, fix, etc),
> > commit it to your local repository. Perhaps do some diffs against your
> master repository and if all is good,
> > merge it with your local master branch. At this point, there is still no
> change to the 'main' master repository.
> > If the merge all goes fine, you can then push the changes to your master
> branch in your main repository. It is
> > only at this point that the changes have been introduced to the main
> repository.
> >
> > So, in short, making a PR has NO impact on the master repository until
> someone with write permission ie.g.
> > the owner, merges the PR into the master repository.
>
> And here you use "master repository" without defining what that is,
> and then use "main master repository" as if it were a different thing
> (is it?).  Should we be surprised that people get confused?
>
>
Fair enough. I will try to clarify and define the terms to make it clearer.


> I think there are 3 repositories involved in this story:
>
>   . the upstream repository, which lives on Savannah
>   . the local clone of the upstream repository on the user's machine
>   . the "forked repository", which is a clone of the clone mentioned
>     in the previous item; this forked repository is also local, and it
>     is where the user makes the changes which will be the subject of
>     the PR
>
> So far so good?
>

No, not quite. We do have 3 repositories, but not quite as you have defined
them.

1. The upstream repository which lives on Savannah. Let's call this the
master repository.
2. Local clone of master repository used by a maintainer. Call this one the
maintenance repository
3. A developers fork of the master repository. This can be anywhere, but
needs a public interface, like https (i.e. github, gitlab, bitbucket etc).
Call this the developers repository.

There is not much difference between a fork and a clone. A fork typically
refers to a clone of a repository which itself is made available for
further cloning/forking on a server somewhere. Changes can be made on the
forked clone, but typically the changes cannot be pushed upstream to the
master repository the forked repository was cloned from. The 3rd repository
above needs to be a fork because it needs to be public and available to
perform a merge following a pull request.

A maintainer is someone who has write access to the master repository
A developer is someone who would like to contribute code. They have read
access (can clone) from the master repository, but do not have write access.

The PR consists of two workflows, the developers workflow and the
maintainers workflow.

The developers workflow is roughly

1. Fork the master repository to some location, creating the developer
repository.
2. Clone the developer repository so that the developer now has a local
repository to work on
3. Make changes and when complete, push to the developers repository.
Often, the changes will be in a feature branch. It would also be normal
practice for the developer to make sure their forked copy is up-to-date and
their changes in their feature branch have been merged with the current
state of the upstream code i.e. pull from upstream, merge master with
feature branch.
4. Make the PR. How this is done would depend on what interfaces are
available, but could be as simple as an email to the maintainer which
requests that the maintainer pull their changes from their developer
repository and merge them into the master repository. The email would need
to include the URL for the developer repository and include any branch
information if required i.e. the changes might be in a feature branch
within the developer repoository.

 The maintainer workflow could be something like

1. Maintainer receives the PR from the developer (how depends on what
interfaces are available, but might just be an email).
2. Maintainer adds the developers repository as another upstream source to
their LOCAL maintenance repository.
3. Maintainer checks out the developers PR branch as a local branch in
their working directory
4. Maintainer does whatever reviews, cleanup, adjustments etc they think
are necessary and commits the branch. This only commits to their local
maintenance repository.
5. Maintainer does any other check, such as verifying copyright or whatever
6. Maintainer now checks out master branch of maintenance repository
(possibly after doing a pull from upstream master repository to ensure
latest code base).
7. Maintainer then merges local PR branch into master branch
8 Maintainer runs tests and verifies merge is good and if happy commits the
master to local maintenance repository with appropriate commit message.

At this point, the PR is only in the local maintenance repository. There
has not yet been any changes made to the master repository, so nobody can
see these changes.

9. Maintainer pushes the local master branch to the upstream master
repository

The maintainer may then choose to do some cleanup work, like removing the
PR branch and PR upsream source from their local maintenance repository (or
they can leave them, they don't use much space and you may get further PRs
from that developer etc).


If so, as previous discussions have established, the issue that is of
> concern is what server should host the "forked repository".  It
> cannot be someone's private machine, because private machines don't
> usually have Git servers, and thus cannot be pulled from.  Richard
> also didn't want this to be Savannah, because then the forked
> repository and its changes could be perceived as "endorsed" by GNU.
> The practical solution is to host this on some nongnu.org server.
>
>
I don't think we need to care. Provided the person making the PR is able to
provide a public interface to their repository, it doesn't matter where it
is hosted. Once the PR is complete, the code is part of the master
repository and the forked developer repository is irrelevant.


-- 
regards,

Tim

--
Tim Cross

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

Re: Why are so many great packages not trying to get included in GNU 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. ]]]

  >   Basically, you add the PR repository to your LOCAL repo and check
  > it out as a branch. Do whatever you need (review, fix, etc), commit it to
  > your local repository. Perhaps do some diffs against your master repository
  > and if all is good, merge it with your local master branch. At this point,
  > there is still no change to the 'main' master repository. If the merge all
  > goes fine, you can then push the changes to your master branch in your main
  > repository. It is only at this point that the changes have been introduced
  > to the main repository.

This is a good way of handling pull requests.  I'm in favor of
supporting them this way.

I've been told that some repo sites do it another way, where they
pull the patch into a branch in the site.  That way has problems.

-- 
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: Why are so many great packages not trying to get included in GNU Emacs?

[Stefan Monnier]

> I've been told that some repo sites do it another way, where they
> pull the patch into a branch in the site.  That way has problems.

I don't know of any system that uses "plain branches" for that.

I believe you've been misled by the fact that many systems represent PRs
*technically* as "branches", but those branches do not appear as regular
branches, so you can't bump into it thinking it's actually
a legitimate branch: you will only find it if you're looking for
a pull request, with no possibility of confusion.


        Stefan

Re: Why are so many great packages not trying to get included in GNU 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. ]]]

  > I believe you've been misled by the fact that many systems represent PRs
  > *technically* as "branches", but those branches do not appear as regular
  > branches, so you can't bump into it thinking it's actually
  > a legitimate branch: you will only find it if you're looking for
  > a pull request, with no possibility of confusion.

I'm goin by what I was told by someone who explained the area to me.

-- 
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: Why are so many great packages not trying to get included in GNU Emacs?

[Andrea Corallo]

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

> That's right.  There is a practical problem, OTOH, which is that
> write/push access to a GNU ELPA package currently means write access to
> all GNU ELPA packages as well as to Emacs's repository.
>
> For this reason, while some GNU ELPA package maintainers can "just push"
> as they see fit, as it should be, others haven't yet been granted this
> right.  This is a problem which we should solve, indeed, for the benefit
> of those less-lucky package maintainers, as well as for the benefit of
> those Emacs maintainers who have to play the middle men, and more
> generally for the benefit of the GNU ELPA archive and hence Emacs users
> since the current situation tends to discourage submissions.
>
> Note that giving write access widely, as we do now, has advantages as
> well, in that it encourages package maintainers to participate in
> development of Emacs more generally.

To me the fact that a number of package maintainers is without write
access sounds quite odd.

If they are trusted to maintain a package they are supposed to have also
the skills to push correctly a git commit.

Looking at other Free Software projects I'm involved I can testify that
trust pays off and I think they should get write access.  My 2 cents.

  Andrea

-- 
akrl@sdf.org

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Tim Cross]

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

I don't think it is quite that simple.

Your not just trusting that person will do the right thing. You are also
trusting that they also have good operational security. It is precisely
this sort of trust model which resulted n a number of GNU/Linux
distributions being compromised in the past. The same thing has occurred
with NPM and other 'public' repositories. It wasn't that people who had
access did the wrong thing, but rather people who had access who failed to
secure their systems adequately.

You only need to do a search of places like github to see how often people
accidentally commit sensitive data or look at the analysis of repositories
that have been compromised to see how often this occured because passwords
were poor, keys were not secured or sensitive data was accidentally posted
to public forums.

The only real solution is one where each package maintainer is isolated
from write access to code/packages they are not authorised to maintain. The
challenge is, such setups usually also result in higher levels of
maintenance overheads and that can often be a challenge for an organisation
which needs to walk a tight line wrt funding.

To make matters worse, typically, it is almost impossible to have good
security retro fitted to a solution this is something which needs to be
designed into the architecture from the start. This means that to fix this
problem would require a considerable amount of work and change. The change
part is extremely difficult as most people simply don't like change (as is
evident in many of the discussions about updating how we handle patches,
pull requests, defaults, etc).

On Fri, 24 Apr 2020 at 07:51, Andrea Corallo <akrl@sdf.org> wrote:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> > That's right.  There is a practical problem, OTOH, which is that
> > write/push access to a GNU ELPA package currently means write access to
> > all GNU ELPA packages as well as to Emacs's repository.
> >
> > For this reason, while some GNU ELPA package maintainers can "just push"
> > as they see fit, as it should be, others haven't yet been granted this
> > right.  This is a problem which we should solve, indeed, for the benefit
> > of those less-lucky package maintainers, as well as for the benefit of
> > those Emacs maintainers who have to play the middle men, and more
> > generally for the benefit of the GNU ELPA archive and hence Emacs users
> > since the current situation tends to discourage submissions.
> >
> > Note that giving write access widely, as we do now, has advantages as
> > well, in that it encourages package maintainers to participate in
> > development of Emacs more generally.
>
> To me the fact that a number of package maintainers is without write
> access sounds quite odd.
>
> If they are trusted to maintain a package they are supposed to have also
> the skills to push correctly a git commit.
>
> Looking at other Free Software projects I'm involved I can testify that
> trust pays off and I think they should get write access.  My 2 cents.
>
>   Andrea
>
> --
> akrl@sdf.org
>
>

-- 
regards,

Tim

--
Tim Cross

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

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Andrea Corallo]

Tim Cross <theophilusx@gmail.com> writes:

> I don't think it is quite that simple.
>
> Your not just trusting that person will do the right thing. You are
> also trusting that they also have good operational security. It is
> precisely this sort of trust model which resulted n a number of GNU/
> Linux distributions being compromised in the past.

IMO the comparison does not stand.  We are not talking about a big
volume of binaries hard to verify that are continuously pushed by
developers.  With the current volume of commits we have on ELPA the eyes
of other developers on elpa-diffs are sufficient.

I believe giving a little more responsibilities to developers is also a
fundamental stimulus to involve them more.

This need for security is most likely not to be beneficial and BTW I'm
not sure is backuped by specific examples of the past happen in the ELPA repo.

Lastly wanted to mention that yeah... as a last resource 'git revert'
exists :)

Regards

  Andrea

-- 
akrl@sdf.org

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Stefan Kangas]

Andrea Corallo <akrl@sdf.org> writes:

> I believe giving a little more responsibilities to developers is also a
> fundamental stimulus to involve them more.

FWIW, I think Andrea is right on the money here and in her previous message.

Of course, giving out commit access more freely will cause occasional
problems and inconveniences.  I think this drawback is heavily
outweighed by the potential benefits.

Best regards,
Stefan Kangas

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Date: Fri, 24 Apr 2020 08:56:20 +0000
> Cc: Yuan Fu <casouri@gmail.com>, ndame <ndame@protonmail.com>,
>  Stefan Monnier <monnier@iro.umontreal.ca>,
>  Emacs developers <emacs-devel@gnu.org>
> 
> I believe giving a little more responsibilities to developers is also a
> fundamental stimulus to involve them more.

Let's please keep this in perspective.  As shown on the project's
Savannah page

  https://savannah.gnu.org/projects/emacs

we currently have 209 people who can commit to ELPA and Emacs
repositories.  Does that sound like we don't give enough people
responsibilities and the trust to go with that?

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Dmitry Gutov]

On 24.04.2020 11:56, Andrea Corallo wrote:
> IMO the comparison does not stand.  We are not talking about a big
> volume of binaries hard to verify that are continuously pushed by
> developers.  With the current volume of commits we have on ELPA the eyes
> of other developers on elpa-diffs are sufficient.

FWIW, as one of the "other developers", I'm not fond of the volume of 
the commits already. Especially when they come from packages which I 
don't personally care about.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Tim Cross]

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

On Fri, 24 Apr 2020 at 18:56, Andrea Corallo <akrl@sdf.org> wrote:

> Tim Cross <theophilusx@gmail.com> writes:
>
> > I don't think it is quite that simple.
> >
> > Your not just trusting that person will do the right thing. You are
> > also trusting that they also have good operational security. It is
> > precisely this sort of trust model which resulted n a number of GNU/
> > Linux distributions being compromised in the past.
>
> IMO the comparison does not stand.  We are not talking about a big
> volume of binaries hard to verify that are continuously pushed by
> developers.  With the current volume of commits we have on ELPA the eyes
> of other developers on elpa-diffs are sufficient.
>
>
That model sounds good, but simply fails in reality. This has long been a
claim of the open source movement - because the code is available, it is
thoroughly reviewed and therefore a lot more secure. Sounds good, but as
has been shown in other projects (consider openSSL for example), this is
not the case. While having access to the code is extremely important,
relying on ad hoc review is a very weak control. Reviewing of software is
complex and time consuming. Those wanting to inuect malicious content are
clever and do so in ways that are extremely difficult to detect. There has
already been 1 reply which indicates the volume of commits is quite large,
which makes the claim that all commits are scrutinized somewhat
questionable.

> I believe giving a little more responsibilities to developers is also a
> fundamental stimulus to involve them more.
>
> This need for security is most likely not to be beneficial and BTW I'm
> not sure is backuped by specific examples of the past happen in the ELPA
> repo.
>
>
The fact it may ot have occurred does not mean it won't. If plans to
increase popularity and number of packages are successful, it is likely the
associated risks will also increase. Past experience is a very poor
indicator when it comes to security - I was never burgled, until I was.


> Lastly wanted to mention that yeah... as a last resource 'git revert'
> exists :)
>

The problem with this approach is the damage has already been done. How bad
that damage is depends on your own op sec, but it could be substantial.

I don't disagree with empowering developers and giving them more
responsibility. Having good security and enabling developers to have more
responsibility are not mutually exclusive. You can have both and despite
popular opinion, it does not have to come with high levels of inconvenience
or maintenance overhead.

A good security model needs to fulfill 3 requirements

1. People only have access to what they need. The current model fails with
this requirement as developers have access to modifying code they are not
responsible for.
2. Simple, reliable and robust. The system needs to be easy to use and
understand. If it is too complicated, it cannot be easily verified or
modified to fit evolving requirements. If it is too hard to use or
unreliable, people will find a means to work around it and often in ways
which severely compromise security. The current model is very convenient,
but due to 1), is not very secure.
3. It needs to be auditable. Things will go wrong and when they do, you
need to be able to identify what has happened and when. Git logs are pretty
useful in this area. However, I don't know what the process is for adding
access, verifying accounts or reviewing access etc.

Having been involved in helping companies recover from security breaches, I
cannot stress enough how much time, resources and effort it takes. Too
often, such breaches are caused by poor security practices of individuals
rather than a lack of security at the server, firewall etc. Individuals are
frequently unaware they have been compromised. Developers often make
mistakes, like accidentally committing test code which contains sensitive
data, committing a private key or config file containing access tokens etc.
A simple revert will not remove such sensitive data. and requires you
realise the error has occurred.

The key point is there is no reason you can't have convenience and
security. There are several models you could adopt which would restrict
developers to only have access to the code they are responsible for which
do not impose high levels of inconvenience or maintenance overhead. The
important thing is to make this a core requirement and not an after thought
as trying to do this retrospectively is always harder and less successful.
If there is to be a real effort to increase the number of packages
considered to be part of GNU Emacs and included in ELPA, then now is the
time to ensure such issues are addressed.

Tim

--
Tim Cross

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

Re: Why are so many great packages not trying to get included in GNU 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. ]]]

  > A good security model needs to fulfill 3 requirements

  > 1. People only have access to what they need. The current model fails with
  > this requirement as developers have access to modifying code they are not
  > responsible for.

Maintaining a specific GNU ELPA package in itsown individual repos
(and automatically copying commits patches from there into GNU ELPA)
would address this.  Only the maintainers of that package, plus a few
Emacs maintainers, would have access to write the per-package repo.

  > 2. Simple, reliable and robust. The system needs to be easy to use and
  > understand. If it is too complicated, it cannot be easily verified or
  > modified to fit evolving requirements.

I think this change would not harm convenience.  I presume the
per-package repo would be as easy to use as the GNU ELPA repo is now.





-- 
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: Why are so many great packages not trying to get included in GNU Emacs?

[Dmitry Gutov]

On 23.04.2020 21:50, Yuan Fu wrote:
> but if it’s in ELPA, you need to take care of commit message formats, submit a patch and wait for someone to review & commit the patch

This part is not really true.

You don't really need to worry about commit message format in ELPA, nor 
wait for code review (if you're the author of the package).

Re: Why are so many great packages not trying to get included in GNU Emacs?

[João Távora]

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

On Thu, Apr 23, 2020 at 8:03 PM Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 23.04.2020 21:50, Yuan Fu wrote:
> > but if it’s in ELPA, you need to take care of commit message formats,
> submit a patch and wait for someone to review & commit the patch
>
> This part is not really true.
>
> You don't really need to worry about commit message format in ELPA, nor
> wait for code review (if you're the author of the package).
>

However, in projects like Eglot, I do review stuff and do ask people
to follow the GNU Commit message format.  Not always, I will
do it for "newbie" committers often, not to burden them with the
red tape, then add a "Co-authored-by:" cookie to the commit
message.  (In fact I just did that for another GNU Elpa package
also hosted on Github, darkroom.el) If someone is serious about
contributing, I ask them to learn the format and I don't see
any resistance.

Anyway, just as a data point, I don't think Eglot has shortage of
committers because of the copyright issue (everyone I've asked
has eventually assigned to Emacs), the commit message
format, or the review process. I've turned down a few contributions
before, because I didn't like them technically, but they eventually
mutate into valid alternatives that do make it in.

João

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

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Clément Pit-Claudel]

On 07/05/2020 13.42, João Távora wrote:
> Not always, I will do it for "newbie" committers often, not to burden
> them with the red tape, then add a "Co-authored-by:" cookie to the
> commit message.

I got confused by this part: why do you need the cookie?

Re: Why are so many great packages not trying to get included in GNU Emacs?

[João Távora]

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

On Thu, May 7, 2020 at 8:54 PM Clément Pit-Claudel <cpitclaudel@gmail.com>
wrote:

> On 07/05/2020 13.42, João Távora wrote:
> > Not always, I will do it for "newbie" committers often, not to burden
> > them with the red tape, then add a "Co-authored-by:" cookie to the
> > commit message.
>
> I got confused by this part: why do you need the cookie?
>

Because I changed the commit message: here's the commit I was
talking about earlier (from git.sv.gnu.org:/srv/git/emacs/elpa.git)

commit 4953ee6f7de4ead0fced02e0da823eafaf5797e0
Author: Ilya Ostapyshyn <ilya.ostapyshyn@gmail.com>
Date:   Thu May 7 20:34:14 2020 +0300

    Fix #13: correctly calculate search bound for narrowed buffers

    The search-forward function does not take narrowing into account, so we
must
    do that  ourselves.

    Co-authored-by: João Távora <joaotavora@gmail.com>
    Copyright-paperwork-exempt: yes

    * darkroom.el (darkroom-guess-margins): Add (point-min) to the 20000

I added all the commit message, but Ilya did the actual patch.

Though reading Luke's email, it seems I could have use
"Signed-off-by:" or something like that.

João

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

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Thu, 7 May 2020 21:28:23 +0100
> Cc: ndame <ndame@protonmail.com>, Yuan Fu <casouri@gmail.com>,
>  Emacs developers <emacs-devel@gnu.org>, Dmitry Gutov <dgutov@yandex.ru>
> 
>  I got confused by this part: why do you need the cookie?
> 
> Because I changed the commit message: here's the commit I was 
> talking about earlier (from git.sv.gnu.org:/srv/git/emacs/elpa.git)
> 
> commit 4953ee6f7de4ead0fced02e0da823eafaf5797e0
> Author: Ilya Ostapyshyn <ilya.ostapyshyn@gmail.com>
> Date:   Thu May 7 20:34:14 2020 +0300
> 
>     Fix #13: correctly calculate search bound for narrowed buffers
>     
>     The search-forward function does not take narrowing into account, so we must
>     do that  ourselves.
>     
>     Co-authored-by: João Távora <joaotavora@gmail.com>
>     Copyright-paperwork-exempt: yes
>     
>     * darkroom.el (darkroom-guess-margins): Add (point-min) to the 20000
> 
> I added all the commit message, but Ilya did the actual patch.
> 
> Though reading Luke's email, it seems I could have use
> "Signed-off-by:" or something like that.

See CONTRIBUTE: we are asking not to use Signed-off-by.

As for Co-authored-by, this is IMO a borderline case: a change in the
commit log message does not necessarily mean you become a co-author.
But it doesn't do any harm, so it's your call whether to use it in
such cases.  I don't, FWIW.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[João Távora]

On Fri, May 8, 2020 at 7:26 AM Eli Zaretskii <eliz@gnu.org> wrote:

> As for Co-authored-by, this is IMO a borderline case: a change in the
> commit log message does not necessarily mean you become a co-author.

I don't think a newbie author would like to see a strange
commit message under his name without warning (tho
I'm guessing: noone has complained).

> But it doesn't do any harm, so it's your call whether to use it in
> such cases.  I don't, FWIW.

Got it.  No Signed-off-by. But just so I understand, you're "borderline"
on Co-authored-by if that is motivated by the commit message
text. You're _not_ opposed to it if I add a comment to code, or
change some detail, right? Because I'll do that sometimes,
too.  Though only for larger changes, and from those authors
I request copyright assignments.

Thanks,
João

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Fri, 8 May 2020 17:28:52 +0100
> Cc: Clément Pit-Claudel <cpitclaudel@gmail.com>, 
> 	ilya.ostapyshyn@gmail.com, ndame <ndame@protonmail.com>, 
> 	Yuan Fu <casouri@gmail.com>, emacs-devel <emacs-devel@gnu.org>, Dmitry Gutov <dgutov@yandex.ru>
> 
> > But it doesn't do any harm, so it's your call whether to use it in
> > such cases.  I don't, FWIW.
> 
> Got it.  No Signed-off-by. But just so I understand, you're "borderline"
> on Co-authored-by if that is motivated by the commit message
> text. You're _not_ opposed to it if I add a comment to code, or
> change some detail, right?

I'm not opposed to it at all.  If you feel you need to add that, I'm
fine with that.  (My own interpretation of co-authorship is that some
serious code change would have to have place, but I see no reason not
to leave this to the discretion of each one of us.)

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> Date: Thu, 23 Apr 2020 17:47:00 +0000
> From: ndame <ndame@protonmail.com>
> 
> Is there an actual effort too seek out prospective packages and ask the
> code owners to include it in emacs?

Yes, in some cases.

> What about current popular packages outside Emacs? Were those developers
> all asked?

Not all of them, but some were asked, yes.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[ndame]

>
> > What about current popular packages outside Emacs? Were those developers
> > all asked?
>
> Not all of them, but some were asked, yes.

And in those cases what were the typical reasons given for refusals?

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Eli Zaretskii]

> Date: Thu, 23 Apr 2020 19:35:07 +0000
> From: ndame <ndame@protonmail.com>
> Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> > > What about current popular packages outside Emacs? Were those developers
> > > all asked?
> >
> > Not all of them, but some were asked, yes.
> 
> And in those cases what were the typical reasons given for refusals?

They varied.  I suggest to look them up in the archives.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Stefan Monnier]

> Is there an actual effort too seek out prospective packages and ask the
> code owners to include it in emacs?

Yes.  I'd say at least half of the packages we currently have in GNU
ELPA are there because we went out and tried to get the authors to
contribute their package to GNU ELPA.
I welcome help in doing that work, BTW.


        Stefan

Re: Why are so many great packages not trying to get included in GNU Emacs?

[ndame]

>
> Yes. I'd say at least half of the packages we currently have in GNU
> ELPA are there because we went out and tried to get the authors to
> contribute their package to GNU ELPA.

An alternative could be adding MELPA too by default to package-archives,
but with a filtered package list.

In order to get into the default MELPA filter a package is required
to have a free license and it has to be a quality package with an
active maintainer.

This way out of the box emacs would be in control what can be installed
from MELPA, so there is less need to move the package into ELPA.
The filter list itself could be in ELPA, so it can be
updated independently of Emacs' release cycle.

And, of course, the user could also modify the filter list in his own
config allowing installation of any package he likes.

Re: Why are so many great packages not trying to get included in GNU 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. ]]]

  > An alternative could be adding MELPA too by default to package-archives,
  > but with a filtered package list.

  > This way out of the box emacs would be in control what can be installed
  > from MELPA, so there is less need to move the package into ELPA.

Yes indeed -- and that is the drawback of that proposal.

We want the developers of the MELPA packages that users like
to sign copyright assignments so we can put those packages into GNU ELPA.

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

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Stefan Kangas]

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

> > Is there an actual effort too seek out prospective packages and ask the
> > code owners to include it in emacs?
>
> Yes.  I'd say at least half of the packages we currently have in GNU
> ELPA are there because we went out and tried to get the authors to
> contribute their package to GNU ELPA.

Interesting; I wasn't aware that it was that many.  Important progress
has clearly been made.

But ideally we would see it happen the other way around: package
maintainers reaching out to us for inclusion.

> I welcome help in doing that work, BTW.

Is there a list of packages we would like to see included and their
current status?  That would definitely make it easier to get involved.
Such a list could also include the packages where we have tried but
hit a dead end.

We could add this to the Emacs TODO and/or a separate file in the ELPA
repository.

Best regards,
Stefan Kangas

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Stefan Monnier]

>> I welcome help in doing that work, BTW.
> Is there a list of packages we would like to see included and their
> current status?

No, sorry.  But yes, it would be good for someone to manage such a list.
Since we welcome pretty much any reasonable package into GNU ELPA, the
starting list can start as "all the packages you use from MELPA".
And packages used by other packages would likely have higher priority
(which is why we worked fairly hard to get `dash` into GNU ELPA, for
example).

> Such a list could also include the packages where we have tried but
> hit a dead end.

Or not dead ends but where we're "in the process".

Other work to do is to make sure the GNU ELPA packages don't
become stale.  E.g. `dash` is out of date, IIRC.

> We could add this to the Emacs TODO and/or a separate file in the ELPA
> repository.

I think it makes more sense to keep it in elpa.git than emacs.git, but
either way works.


        Stefan

Re: Why are so many great packages not trying to get included in GNU 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. ]]]

  > Yes.  I'd say at least half of the packages we currently have in GNU
  > ELPA are there because we went out and tried to get the authors to
  > contribute their package to GNU ELPA.

Thanks to you and the others who helped do this.

  > I welcome help in doing that work, BTW.

I encourage others to join in this.


-- 
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: Why are so many great packages not trying to get included in GNU Emacs?

[Jean-Christophe Helary]

> On Apr 24, 2020, at 5:52, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
>> Is there an actual effort too seek out prospective packages and ask the
>> code owners to include it in emacs?
> 
> Yes.  I'd say at least half of the packages we currently have in GNU
> ELPA are there because we went out and tried to get the authors to
> contribute their package to GNU ELPA.

I seem to remember that in the summer of 2017 and after, Mats Lidell and I, led by Jonas Bernoulli did something very similar for packages hosted on emacsmirror, after a discussion here about copyright assignments and licenses.

> I welcome help in doing that work, BTW.

If you have clear instructions, I could help.


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Po Lu]

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


> Yes.  I'd say at least half of the packages we currently have in GNU
> ELPA are there because we went out and tried to get the authors to
> contribute their package to GNU ELPA.
> I welcome help in doing that work, BTW.

BTW, has there been any real progress in including Magit in ELPA?
I remember a discussion pertaning to that and it seemed promising at the
time, but now I can't find anything related to it.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[ndame]

> An unwillingness to assign copyright to the FSF, seemingly often more due to
>  inertia than any principled opposition.

Getting papers from others is a burden. Most code these days live
on GitHub where it's very easy to submit and merge pull requests.

If a package needs assignment then the maintainer cannot accept code until
the copyright is assigned which is an administrative hoop which nor the
maintainer, nor the submitter may want to deal with.

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Rostislav Svoboda]

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

> If a package needs assignment then the maintainer cannot accept code
until the copyright is assigned which is an administrative hoop which nor
the maintainer, nor the submitter may want to deal with

Some years ago I wrote a little patch (~30 LOC, IIRC) for the yasnippet and
got it rejected because it was a few lines longer than the limit for a
patch without an assigned copyright.

I tried to game the systems, I split the patch and I asked a buddy of mine
to submit the first half under his name to stay under the line-limit and
avoid the assignment procedure. That didn't work out. I didn't feel like I
should really invest that much energy into to the cover-up of my little
work and the yasnippet maintainer isn't that naive.

So I capitulated and proceeded with the FSF copyright assignment paperwork.
That went rather quickly, maybe just 2 or 3 days... and after receiving it
I felt pretty proud of myself being officially(!) an "open source dev"
dude. Except that I haven't resubmit the patch nor did contribute in any
other way to the emacs core parts or packages. My attention span was over.
Sorry about that.

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

Re: Why are so many great packages not trying to get included in GNU Emacs?

[Noam Postavsky]

On Thu, 23 Apr 2020 at 20:51, Rostislav Svoboda
<rostislav.svoboda@gmail.com> wrote:
>
> > If a package needs assignment then the maintainer cannot accept code until the copyright is assigned which is an administrative hoop which nor the maintainer, nor the submitter may want to deal with
>
> Some years ago I wrote a little patch (~30 LOC, IIRC) for the yasnippet and got it rejected because it was a few lines longer than the limit for a patch without an assigned copyright.
>
> I tried to game the systems, I split the patch and I asked a buddy of mine to submit the first half under his name to stay under the line-limit and avoid the assignment procedure. That didn't work out. I didn't feel like I should really invest that much energy into to the cover-up of my little work and the yasnippet maintainer isn't that naive.

If you refer to https://github.com/joaotavora/yasnippet/pull/746, as
far I recall, I didn't merge it because there wasn't an
explanation/description of the change in the commit messages (or
elsewhere), so I couldn't really understand what it was fixing. It
looks like you deleted the patch, but according to my comments there
it would probably have fallen under the "regular series of repeated
changes, such as renaming a symbol, is not legally significant even if
the symbol has to be renamed in many places" as described in
https://www.gnu.org/prep/maintain/maintain.html#Legally-Significant so
it might not even have exceeded the limit anyway.