ELPA: where is chess developed?

ELPA: where is chess developed?

[Jack Hill]

Hi Emacs,

I'm interested in working with the Chess package. According to 
1b67906a62fe84cf838f7bb88675af69e0efff13 [0], Chess is developed in the 
the main ELPA repository. However, it seems that the previous upstream 
location [1] has seen more development activity than the external/chess 
branch [2].

[0] https://git.savannah.gnu.org/cgit/emacs/elpa.git/commit/?id=1b67906a62fe84cf838f7bb88675af69e0efff13
[1] https://github.com/jwiegley/emacs-chess
[2] https://git.savannah.gnu.org/cgit/emacs/elpa.git/log/?h=externals/chess

What's going on here? Did the project fork and there are two development 
streams going forward? Did the aspiration to develop chess in the ELPA 
repository fail, and we should switch back to jwiegley/emacs-chess as 
upstream? If I package this for my distribution, which one should I use?

Please copy me on replies.

Thanks,
Jack

Re: ELPA: where is chess developed?

[John Wiegley]

>>>>> "JH" == Jack Hill <jackhill@jackhill.us> writes:

JH> What's going on here? Did the project fork and there are two development
JH> streams going forward? Did the aspiration to develop chess in the ELPA
JH> repository fail, and we should switch back to jwiegley/emacs-chess as
JH> upstream? If I package this for my distribution, which one should I use?

I believe that Mario Lang is currently the most active developer, and that he
organized releases to ELPA. Whether that's the home seat of development or
not, I would ask of him. Mario?

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

Re: ELPA: where is chess developed?

[dick.r.chiang]

Hi John,

The situation looks grim indeed -- a quick inspection shows development
streams between [1] and [2] to have diverged 20140604 (the last "Sync from ELPA"
commit).

I believe I've the time and taste to get them back in sync, but I think I need
push access to savannah, of which I've been denied in the past (and perhaps
with good reason).

[0] https://git.savannah.gnu.org/cgit/emacs/elpa.git/commit/?id=1b67906a62fe84cf838f7bb88675af69e0efff13

[1] https://github.com/jwiegley/emacs-chess

[2] https://git.savannah.gnu.org/cgit/emacs/elpa.git/log/?h=externals/chess

Re: ELPA: where is chess developed?

[Mario Lang]

dick.r.chiang@gmail.com writes:

> Hi John,
>
> The situation looks grim indeed -- a quick inspection shows development
> streams between [1] and [2] to have diverged 20140604 (the last "Sync from ELPA"
> commit).
>
> I believe I've the time and taste to get them back in sync, but I think I need
> push access to savannah, of which I've been denied in the past (and perhaps
> with good reason).

git should make it relatively easy for you to provide a branch
somewhere which I (or someone else with ELPA access) could merge
after a review.  So I dont see why missing push access would be a
showstopper.  (Thanks for caring btw).

-- 
CYa,
  ⡍⠁⠗⠊⠕

Re: ELPA: where is chess developed?

[dick.r.chiang]

I'm afraid I'm the type of programmer who requires the tight feedback loop
that push access affords.  I understand "moving fast and possibly breaking
things" is becoming increasingly out of fashion.

Re: ELPA: where is chess developed?

[Philippe Vaucher]

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

On Mon, Mar 23, 2020 at 4:13 PM <dick.r.chiang@gmail.com> wrote:

> I'm afraid I'm the type of programmer who requires the tight feedback loop
> that push access affords.  I understand "moving fast and possibly breaking
> things" is becoming increasingly out of fashion.
>

Just curious, can you elaborate why the ability to push gives you a tight
feedback loop?

I often work with repositories where I have several remotes, maybe there's
a missunderstanding I can clear.

Kind regards,
Philippe

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

Re: ELPA: where is chess developed?

[dick.r.chiang]

> Just curious, can you elaborate why the ability to push gives you a tight
> feedback loop?

Notice how belabored the email-patch mechanism is for prospective
contributors without push access.  Nature of the beast I'm afraid... there's
always at least one niggling fixup for the smallest patch submission, and for a
50-commit-behind-50-commit-ahead merge, there's going to be order of 10
fixups.  The verbal back-and-forth required is prohibitively costly for a
largely inactive repo like emacs-chess.

The web-based "pull request" mechanism is much more sane than iterating emails
as it's always clear which of the author's iterations is latest, but that's a
separate issue.

Re: ELPA: where is chess developed?

[Philippe Vaucher]

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

> > Just curious, can you elaborate why the ability to push gives you a tight
> > feedback loop?
>
> Notice how belabored the email-patch mechanism is for prospective
> contributors without push access.  Nature of the beast I'm afraid...
> there's
> always at least one niggling fixup for the smallest patch submission, and
> for a
> 50-commit-behind-50-commit-ahead merge, there's going to be order of 10
> fixups.  The verbal back-and-forth required is prohibitively costly for a
> largely inactive repo like emacs-chess.
>
> The web-based "pull request" mechanism is much more sane than iterating
> emails
> as it's always clear which of the author's iterations is latest, but
> that's a
> separate issue.
>

Ah, I understood something else. I agree with what you say.

Question for maintainers: is it actually mandatory that all changes are
submitted through patches on the ML? If we need to submit lot of
patches, can we just point to an external repository on some branch?

Kind regards,
Philippe

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

Re: ELPA: where is chess developed?

[Stefan Monnier]

> Question for maintainers: is it actually mandatory that all changes are
> submitted through patches on the ML? If we need to submit lot of
> patches, can we just point to an external repository on some branch?

I like branches on public repositories better than patches when it's
time to install it.  I like patches in email better when it comes to
reviewing.


        Stefan

Re: ELPA: where is chess developed?

[Stefan Monnier]

>> Question for maintainers: is it actually mandatory that all changes are
>> submitted through patches on the ML? If we need to submit lot of
>> patches, can we just point to an external repository on some branch?
>
> I like branches on public repositories better than patches when it's
> time to install it.  I like patches in email better when it comes to
> reviewing.

Sorry, I sent it before finishing it.  The two remaining items were:
- email patches suck for large changes (even if it's only for review).
- these are just preferences, but I'm fine with either.


        Stefan

pull requests

[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 had a discussion last year about support for pull requests.  The
problem that we identified last year is that allowing proposed patches
into a GNU forge breaks down the simple wall between what the GNU
Project distributes and users' changes.

In place of that simple wall, there would be a criterion that requires
judgment.  Emacs developers would understand that criterion, but the
public and the courts would not reliably understand.  This could cause
problems of a legal nature, problems of a moral nature, and problems
of explanation.

The legal problems: there could be code without copyright assignments.
The moral problems: there could be code that isn't free.
The explanatoy problems: there could be code or comments that contradict
our message.

I don't remember the precise conclusions last year, but ISTR I
concluded that any pull requests on a GNU forge must be visible _only_
to the developers of the package.

Can someone find that previous discussion and show its actual conclusions?
With a single Message-ID field I could find the discussion.

  > Question for maintainers: is it actually mandatory that all changes are
  > submitted through patches on the ML? If we need to submit lot of
  > patches, can we just point to an external repository on some branch?

I don't feel confident I understand that concretely -- what precisely
would be "on some branch"?

Maybe it is ok to point to an external repository in an email to
emacs-devel.  I'd want to have a discussion of that, but I tend to
think that if done properly it is basically equivalent to emailing the
patches themselves to emacs-devel.

The external repo should not be on a site such as GitHub that requires
Javascript to do things users will want to do with that repo.  And it
should be clearly labeled as "XYZ's patched version of GNU Emacs M.N,
containing changes submitted for installation."

-- 
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: pull requests

[Stefan Monnier]

> In place of that simple wall, there would be a criterion that requires
> judgment.  Emacs developers would understand that criterion, but the
> public and the courts would not reliably understand.  This could cause
> problems of a legal nature, problems of a moral nature, and problems
> of explanation.
>
> The legal problems: there could be code without copyright assignments.

I don't see the problem: many packages on Savannah don't have their
copyright assigned to the FSF, so the FSF's servers have been
distributing code without copyright assignments for years already.
Nothing new here.


        Stefan

Re: pull requests

[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 legal problems: there could be code without copyright assignments.

  > I don't see the problem: many packages on Savannah don't have their
  > copyright assigned to the FSF, so the FSF's servers have been
  > distributing code without copyright assignments for years already.

You have equated two different kinds of cases:
FSF-copyrighted packages and non-FSF-copyrighted packages.
Emacs is an FSF-copyrighted package, so we do not allow code into
the repo unless it has a copyright assignment.

This is a legal policy, not a technical one.  To change it for
merely technical reasons would be to let the tail wag the dog.

-- 
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: pull requests

[Stefan Monnier]

>   > > The legal problems: there could be code without copyright assignments.
>   > I don't see the problem: many packages on Savannah don't have their
>   > copyright assigned to the FSF, so the FSF's servers have been
>   > distributing code without copyright assignments for years already.
> You have equated two different kinds of cases:
> FSF-copyrighted packages and non-FSF-copyrighted packages.
> Emacs is an FSF-copyrighted package, so we do not allow code into
> the repo unless it has a copyright assignment.

Yes, but it's a choice we make.  Not following it wouldn't get us into
legal trouble.

> This is a legal policy, not a technical one.

It's a strategic decision, AFAIK, i.e. dictated neither by technical nor
legal requirements.  Which is why the GNU project applies to some
packages and not all.

> To change it for merely technical reasons would be to let the tail wag
> the dog.

I was not arguing to change this policy.  I was just pointing out that
whether or not there is non-assigned Emacs-related code somewhere on
gnu.org is not a legal problem, AFAIK.  Neither do I think it would
weaken the FSF's hand in case it had to defend its copyright on the
actual Emacs code (assuming we keep following the policy that we only
accept copyright-assigned code into it, obviously).


        Stefan

Re: pull requests

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Thu, 26 Mar 2020 22:59:35 -0400
> Cc: mlang@delysid.org, jackhill@jackhill.us, dick.r.chiang@gmail.com,
>  emacs-devel@gnu.org
> 
> I don't remember the precise conclusions last year, but ISTR I
> concluded that any pull requests on a GNU forge must be visible _only_
> to the developers of the package.

IIRC, the most important, at least IMO, conclusion was that we should
host such services on savannah.nongnu.org, so that any code in those
pull requests is not considered to "belong to GNU".

> Can someone find that previous discussion and show its actual conclusions?
> With a single Message-ID field I could find the discussion.

It was on gnu-prog-discuss, not here.  One message-ID I have from that
discussion is 871rv8suni.fsf@gnu.org.

There was some "shadow" of that in this mailing list in last November,
try message-ID 83sgmhxp1i.fsf@gnu.org.

>   > Question for maintainers: is it actually mandatory that all changes are
>   > submitted through patches on the ML? If we need to submit lot of
>   > patches, can we just point to an external repository on some branch?
> 
> I don't feel confident I understand that concretely -- what precisely
> would be "on some branch"?
> 
> Maybe it is ok to point to an external repository in an email to
> emacs-devel.  I'd want to have a discussion of that, but I tend to
> think that if done properly it is basically equivalent to emailing the
> patches themselves to emacs-devel.

That's a different proposal altogether, AFAIU.  From my POV, it makes
the lives of those who submit patches easier, but complicates the
lives of those who review patches, because pulling those changes into
our local repository for testing them is then more complex, and
requires access to Git servers about whose security we may not know
enough to feel confident.  More importantly, given that I did a review
of such a remote branch, how do I communicate my comments so that they
are recorded for posterity?  Probably by email, so that doesn't seem
to solve the main problem of avoiding email in the patch submission
and review workflow.

Btw, for an independent lookout and POV of these and related issues,
please see this recent discussion on the GCC mailing list:

  https://gcc.gnu.org/pipermail/gcc/2020-March/000113.html

Re: pull requests

[Clément Pit-Claudel]

On 27/03/2020 03.54, Eli Zaretskii wrote:
> More importantly, given that I did a review
> of such a remote branch, how do I communicate my comments so that they
> are recorded for posterity?  Probably by email, so that doesn't seem
> to solve the main problem of avoiding email in the patch submission
> and review workflow.

Assuming you use the web UI, you can typically attach comments to code regions.

Pros over email reviews include the fact that the comments remain attached to the code even after the patch is updated (so if the original author updates an unrelated section of the patch the comments don't disappear) and the fact that you get to see the full code, rather than just the patch.

Cons include inferior text-editing capabilities, and inferior code browsing capabilities compared to applying the patch and browsing around in Emacs (but you can always checkout the branch, which I find nicer than applying patches by hand anyway).

Clément.

Re: pull requests

[Eli Zaretskii]

> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Fri, 27 Mar 2020 09:00:10 -0400
> 
> On 27/03/2020 03.54, Eli Zaretskii wrote:
> > More importantly, given that I did a review
> > of such a remote branch, how do I communicate my comments so that they
> > are recorded for posterity?  Probably by email, so that doesn't seem
> > to solve the main problem of avoiding email in the patch submission
> > and review workflow.
> 
> Assuming you use the web UI, you can typically attach comments to code regions.

And how does one point to such past discussions, or more generally
make sure they end up in some centralized place we could later
revisit?

Re: pull requests

[Clément Pit-Claudel]

On 27/03/2020 09.30, Eli Zaretskii wrote:
>> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
>> Date: Fri, 27 Mar 2020 09:00:10 -0400
>>
>> On 27/03/2020 03.54, Eli Zaretskii wrote:
>>> More importantly, given that I did a review
>>> of such a remote branch, how do I communicate my comments so that they
>>> are recorded for posterity?  Probably by email, so that doesn't seem
>>> to solve the main problem of avoiding email in the patch submission
>>> and review workflow.
>>
>> Assuming you use the web UI, you can typically attach comments to code regions.
> 
> And how does one point to such past discussions, or more generally
> make sure they end up in some centralized place we could later
> revisit?

These comments survive even after the pull request is merged, so the tracker that hosted the discussion and the code comments acts as that centralized place.

Here is a good example, from GTK, which moved to gitlab a while ago with the rest of Gnome: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/1158 (gitlab calls them "merge requests")

On that page you can see many sections that say `… started a thread on an outdated change`.  This means that a project maintainer (or anyone, really) commented on part of the patch, then the original patch author (or anyone able to push to the corresponding branch) updated the code (hence the "outdated" part — but note that the diff under discussion is still available).  The part that says `Resolved by … 4 months ago' means that the author or the original commenter indicated that the particular point under discussion had been resoled, so that discussion is now hidden by default to reduce noise.

Here is another example, from nautilus: https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/417.  In both cases the changes have been applied to the master branch ("merged"), but the discussion persists in the tracker.

HTH,
Clément.

Re: pull requests

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Fri, 27 Mar 2020 10:37:38 -0400
> 
> >> Assuming you use the web UI, you can typically attach comments to code regions.
> > 
> > And how does one point to such past discussions, or more generally
> > make sure they end up in some centralized place we could later
> > revisit?
> 
> These comments survive even after the pull request is merged, so the tracker that hosted the discussion and the code comments acts as that centralized place.

So we are supposed to keep pointers to those sites, and use them?  How
do we know which site holds what relevant discussions? who will
remember that several years after the discussion took place?  And what
if the tracker that hosted the discussion goes dark (e.g., because the
person who submitted the patch is no longer keeping the branch, or
simply because the hosting service is discontinued?

I really don't see how a project that is 30-something years old, and
intends to live for several more decades, can possibly rely on such
infrastructure for discussions that might prove important years from
now.  We must have all these archives in a single place, which we can
control and which we can ensure continues to be available for years to
come.

Re: pull requests

[Dmitry Gutov]

On 27.03.2020 17:21, Eli Zaretskii wrote:
> So we are supposed to keep pointers to those sites, and use them?  How
> do we know which site holds what relevant discussions? who will
> remember that several years after the discussion took place?

"The site" is the forge we would be using. E.g. a local installation of 
Gitlab, known to all. Or some other forge software.

> And what
> if the tracker that hosted the discussion goes dark (e.g., because the
> person who submitted the patch is no longer keeping the branch, or
> simply because the hosting service is discontinued?

One more reason to host PRs on the official forge installation, not on 
some faraway mirrors.

Nobody mistakes submitted patches on the mailing list for the official 
GNU code. There is no reason for anyone to mistake the submitted PRs for 
that either.

That section is literally "contributions under consideration", why would 
anyone think it's the project code already?

Re: pull requests

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 27 Mar 2020 17:41:00 +0200
> 
> On 27.03.2020 17:21, Eli Zaretskii wrote:
> > So we are supposed to keep pointers to those sites, and use them?  How
> > do we know which site holds what relevant discussions? who will
> > remember that several years after the discussion took place?
> 
> "The site" is the forge we would be using. E.g. a local installation of 
> Gitlab, known to all. Or some other forge software.

That's not the proposal that prompted Clément's comments and my
response.  It was a proposal to have us review patches on remote
branches that people push to their own repositories.  See

  https://lists.gnu.org/archive/html/emacs-devel/2020-03/msg00617.html

Re: pull requests

[Dmitry Gutov]

On 27.03.2020 21:16, Eli Zaretskii wrote:
> That's not the proposal that prompted Clément's comments and my
> response.  It was a proposal to have us review patches on remote
> branches that people push to their own repositories.  See
> 
>    https://lists.gnu.org/archive/html/emacs-devel/2020-03/msg00617.html

OK, in that case I agree it's not a great choice.

Re: pull requests

[조성빈]

> 2020. 3. 28. 오전 4:17, Eli Zaretskii <eliz@gnu.org> 작성:
> 
> 
>> 
>> Cc: emacs-devel@gnu.org
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Fri, 27 Mar 2020 17:41:00 +0200
>> 
>>> On 27.03.2020 17:21, Eli Zaretskii wrote:
>>> So we are supposed to keep pointers to those sites, and use them?  How
>>> do we know which site holds what relevant discussions? who will
>>> remember that several years after the discussion took place?
>> 
>> "The site" is the forge we would be using. E.g. a local installation of 
>> Gitlab, known to all. Or some other forge software.
> 
> That's not the proposal that prompted Clément's comments and my
> response.  It was a proposal to have us review patches on remote
> branches that people push to their own repositories.  See
> 
>  https://lists.gnu.org/archive/html/emacs-devel/2020-03/msg00617.html
> 

My understanding was that the contributor wanted push access to a branch because one didn’t like the convoluted email-patch workflow, but getting push access to ELPA is hard so one wanted to point another beach firm an external repo(which he has push access to).

Which would mean if there can be a (nongnu) forge that people can ‘fork’ the Emacs/ELPA repo, commit/push and open a PR to the main repo, one wouldn’t need to point to an external repo. One could just point to a fork of repo on the nongnu forge in this case.

Re: pull requests

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 27 Mar 2020 17:41:00 +0200
> Cc: emacs-devel@gnu.org
> 
> One more reason to host PRs on the official forge installation, not on 
> some faraway mirrors.
> 
> Nobody mistakes submitted patches on the mailing list for the official 
> GNU code. There is no reason for anyone to mistake the submitted PRs for 
> that either.
> 
> That section is literally "contributions under consideration", why would 
> anyone think it's the project code already?

This is a different discussion.  We had that at least twice in the
past, we identified the issues that need to be resolved for us to
start the migration, and from my POV we are waiting for volunteers to
work on resolving those issues.

Re: pull requests

[Dmitry Gutov]

On 27.03.2020 21:28, Eli Zaretskii wrote:

>> That section is literally "contributions under consideration", why would
>> anyone think it's the project code already?
> 
> This is a different discussion.  We had that at least twice in the
> past, we identified the issues that need to be resolved for us to
> start the migration, and from my POV we are waiting for volunteers to
> work on resolving those issues.

Ah, very good. Thanks for confirming that.

Because the recent sentiments expressed by fellow developers about Web 
UIs, etc, looked kind of discouraging. Richard's conclusion that PRs 
can't be publicly-accessible would also be a complication, and also 
something of a missed opportunity WRT making the development process 
more accessible and visible to the public.

Reading the news about FSF evaluating forge softwares, I figured that's 
the best change for us to get something similar in Emacs development.

Re: pull requests

[Richard Stallman]

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

  > That section is literally "contributions under consideration",

That is a statement of intentions, not facts.  Emacs developers
would know those intentions, but other Emacs users might have no
idea about them.


								   why would 
  > anyone think it's the project code already?

Why wouldn't anyone thing so?  Are you proposing to display a message
of explanation whenever someone tries to view the code in a pull request?

Suppose A sends B a URL pointing to a branch with non-installed
patches.  If A doesn't warn B; if A is too terse and does not make the
point clear, B will not know it is non-installed.  B will only see
that it is in the standard GNU Emacs repo.

This is asking for big trouble.  Versions of Emacs that by policy
we should not be distributing could start being distributed in that way,
and no responsible person would ever be asked whether to do 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: pull requests

[Dmitry Gutov]

On 28.03.2020 04:46, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>    > That section is literally "contributions under consideration",
> 
> That is a statement of intentions, not facts.  Emacs developers
> would know those intentions, but other Emacs users might have no
> idea about them.

That's why we have forges, with self-explanatory web interfaces and even 
integrated help for new users.

> 								   why would
>    > anyone think it's the project code already?
> 
> Why wouldn't anyone thing so?  Are you proposing to display a message
> of explanation whenever someone tries to view the code in a pull request?

99% of the users who would be looking at them, would be doing so through 
the web interface of the force software. And at that web page it would 
be made apparent that the user is looking at a pull request.

> Suppose A sends B a URL pointing to a branch with non-installed
> patches.  If A doesn't warn B; if A is too terse and does not make the
> point clear, B will not know it is non-installed.  B will only see
> that it is in the standard GNU Emacs repo.

When you were talking about hiding PRs from non-developers, you meant 
hiding in the web interface, right? Because it would be hard to hide 
them in the mailing lists, for example, considering they're all public.

Anyway, if the branch is not called master or emacs-xx, then it's 
relatively obvious that it contains some code that is yet to incorporated.

> This is asking for big trouble.  Versions of Emacs that by policy
> we should not be distributing could start being distributed in that way,
> and no responsible person would ever be asked whether to do this.

As per above, I think it would be hard to mistake a non-official branch 
for an official one. But that brings us to the question of whether we 
would allow unauthenticated users to create new branches in our forge.

The previous discussion concluded on "probably not", and then the 
situation is not different from the current one: pull requests (or 
"merge requests") would be created only by the current developers who 
have commit access.

But if we manage to support merge requests from contributors without 
commit access, and do it without external repositories, we could just as 
well mandate that all such branches have names prefixed with 
"merge-request/", and that will avoid any confusion.

Also, if any branches in our repo end up containing really problematic 
code, I'm sure that can be dealt with on a case-by-case basis.

Re: pull requests

[Richard Stallman]

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

  > > That is a statement of intentions, not facts.  Emacs developers
  > > would know those intentions, but other Emacs users might have no
  > > idea about them.

  > That's why we have forges, with self-explanatory web interfaces and even 
  > integrated help for new users.

That would inform some users, those who do certain things.  But in the
scenario I pointed at, the users would not do those things, so they
would not get the information.

This is the scenario I pointed at:

   Suppose A sends B a URL pointing to a branch with non-installed
   patches.  If A doesn't warn B, or if A is too terse and does not make the
   point clear, B will not know it is non-installed.  B will only see
   that it is in the standard GNU Emacs repo.

  > 99% of the users who would be looking at them, would be doing so through 
  > the web interface of the force software.

In that scenario, large numbers of users might not go through that interface.
They might not even know there is a web interface.

  > When you were talking about hiding PRs from non-developers, you meant 
  > hiding in the web interface, right? 

I mean blocking access to them _in the repo_, for all interfaces.  If
you're not logged in as a member of the project, you would not be
allowed to check out that branch by running git.

					Because it would be hard to hide 
  > them in the mailing lists,

The mailing list is a different kind issue.  If you abstract away
the practical differences, you might think it is the same; but those
practicalities change everything, in this case.

I am not talking about adding security where we have done ok without
it.  My aim is to limit the possible new danger from the change that
you are asking for.

I know that many other projects use pull requests and are happy with them.
But those projects do not share our nontechnical overriding goals:

* Do not distribute nonfree software.
* Do not publish text that recommends nonfree software.
* For some projects, do not include code without legal papers.

We have a system for avoiding this: the package maintainers decide
what to install, and they check these criteria before installing
anything.  (See the GNU Coding Standards and GNU Maintainer's Guide.)

Keeping uninstalled code in the same repo as the installed code makes
it too easy to overlook the difference between them.

  > But if we manage to support merge requests from contributors without 
  > commit access, and do it without external repositories, we could just as 
  > well mandate that all such branches have names prefixed with 
  > "merge-request/", and that will avoid any confusion.

I am not convinced it would work "just as well."  But that idea is
worth thinking about.  we need to think _not only_ about how we would
intend this facility to be used, but also how to make sure it is not
misused.

How, in practice, would we ensure that all installation proposals
have a name starting with 'merge-request/'?

How would we find out if many users begin accessing a branch whose
name begins with 'merge-request/'?

How would we find out if one is created with a name that doesn't
start with that prefix?

Could we arrange that those branches start out accessible only to
maintainers, then become generally accessible when a maintainer says
"Make this accessible"?



-- 
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: pull requests

[Stefan Monnier]

>    Suppose A sends B a URL pointing to a branch with non-installed
>    patches.  If A doesn't warn B, or if A is too terse and does not make the
>    point clear, B will not know it is non-installed.  B will only see
>    that it is in the standard GNU Emacs repo.
[...]
> In that scenario, large numbers of users might not go through that interface.
> They might not even know there is a web interface.

I don't follow: in all likelihood, that URL that A sends to B points to
the web interface (at least, that's what I saw in 100% of the cases
with github and gitlab).


        Stefan

Re: pull requests

[Eli Zaretskii]

On March 30, 2020 7:09:55 AM GMT+03:00, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
> I don't follow: in all likelihood, that URL that A sends to B points
> to
> the web interface (at least, that's what I saw in 100% of the cases
> with github and gitlab).
>

IME, that URL is both for the Web interface and for accessing the repository.  If you point a browser there, you get the Web interface; if you clone from that URL, you get the code.

Re: pull requests

[Dmitry Gutov]

On 30.03.2020 08:58, Eli Zaretskii wrote:
> IME, that URL is both for the Web interface and for accessing the repository.  If you point a browser there, you get the Web interface; if you clone from that URL, you get the code.

Is that right?

I wasn't able to 'git clone'

   https://emba.gnu.org/emacs/emacs/-/merge_requests/1

or

   https://gitlab.com/eufs/eufs_sim/-/merge_requests/38

(the second one is definitely publicly available).

And anyway, it's a URL with the words "merge request" in it. So nobody 
should mistake it for an official distribution of any sort.

The only possibility of a mistake I was discussing was somebody linking 
for the branch directly (which is not something people do often), or 
basically intentional abuse of our code hosting platform.

Re: pull requests

[Yuri Khan]

On Mon, 30 Mar 2020 at 19:04, Dmitry Gutov <dgutov@yandex.ru> wrote:

> I wasn't able to 'git clone'
>
>    https://gitlab.com/eufs/eufs_sim/-/merge_requests/38

You do not clone a branch. You clone a repository and check out a
merge request branch from it. And that branch is in a namespace that
does not get fetched by default, you have to do some [non-trivial
dance][1] to fetch it.

[1]: https://docs.gitlab.com/ee/user/project/merge_requests/reviewing_and_managing_merge_requests.html#checkout-merge-requests-locally

    $ git clone https://gitlab.com/eufs/eufs_sim
    $ git fetch origin merge-requests/38/head:mr-38
    $ git checkout mr-38

There is no possibility that somebody will do that by mistake and
assume an official distribution.

Re: pull requests

[Eli Zaretskii]

> Cc: cpitclaudel@gmail.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 30 Mar 2020 15:03:36 +0300
> 
> On 30.03.2020 08:58, Eli Zaretskii wrote:
> > IME, that URL is both for the Web interface and for accessing the repository.  If you point a browser there, you get the Web interface; if you clone from that URL, you get the code.
> 
> Is that right?
> 
> I wasn't able to 'git clone'
> 
>    https://emba.gnu.org/emacs/emacs/-/merge_requests/1
> 
> or
> 
>    https://gitlab.com/eufs/eufs_sim/-/merge_requests/38

Try the repo URL, not the merge-request URL.  People point to the repo
very frequently, you can find such references even in this list.

> The only possibility of a mistake I was discussing was somebody linking 
> for the branch directly (which is not something people do often), or 
> basically intentional abuse of our code hosting platform.

That is what happens, yes.

Re: pull requests

[Dmitry Gutov]

On 30.03.2020 16:12, Eli Zaretskii wrote:
> Try the repo URL, not the merge-request URL.  People point to the repo
> very frequently, you can find such references even in this list.

That seems irrelevant to the question of showing or hiding merge 
requests. It's orthogonal.

It's an issue of whether to co-host several repositories, which I agree 
is pertinent, but since GitLab doesn't support fast forking, is too 
early to discuss.

And in the approach we've been discussing (AFAIU) there will be only one 
repo, and as such only one repo URL.

Re: pull requests

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, rms@gnu.org,
>  cpitclaudel@gmail.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 30 Mar 2020 16:50:59 +0300
> 
> On 30.03.2020 16:12, Eli Zaretskii wrote:
> > Try the repo URL, not the merge-request URL.  People point to the repo
> > very frequently, you can find such references even in this list.
> 
> That seems irrelevant to the question of showing or hiding merge 
> requests. It's orthogonal.

It is relevant because I've seen people pointing to the repository,
not to a specific branch or merge request.

Re: pull requests

[Dmitry Gutov]

On 30.03.2020 17:12, Eli Zaretskii wrote:
> It is relevant because I've seen people pointing to the repository,
> not to a specific branch or merge request.

You can't point to the wrong repository when there's just one 
(canonical) repository.

Re: pull requests

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, rms@gnu.org,
>  cpitclaudel@gmail.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 30 Mar 2020 17:34:05 +0300
> 
> On 30.03.2020 17:12, Eli Zaretskii wrote:
> > It is relevant because I've seen people pointing to the repository,
> > not to a specific branch or merge request.
> 
> You can't point to the wrong repository when there's just one 
> (canonical) repository.

Which is exactly the problem: that people will think what they get is
canonical codebase, all of it.

Anyway, I don't understand why we are still arguing.  The basic
guidelines to go by were agreed upon many moons ago, what's left is
for motivated individuals who have enough time on their hands to make
this happen.

Re: pull requests

[Dmitry Gutov]

On 30.03.2020 18:36, Eli Zaretskii wrote:
> Which is exactly the problem: that people will think what they get is
> canonical codebase, all of it.

I don't think so: anyone who's ever worked with branches knows that the 
code in there only gets into the final product once merged into one of 
the "main" ones. After which the branches are normally deleted.

 > Anyway, I don't understand why we are still arguing.  The basic
guidelines to go by were agreed upon many moons ago, what's left is
for motivated individuals who have enough time on their hands to make
this happen.

This discussion was revived when Richard said that pull requests should 
be "hidden". Which is a novel request.

Re: pull requests

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 30 Mar 2020 18:50:35 +0300
> Cc: cpitclaudel@gmail.com, monnier@iro.umontreal.ca, rms@gnu.org,
>  emacs-devel@gnu.org
> 
> This discussion was revived when Richard said that pull requests should 
> be "hidden". Which is a novel request.

AFIU, that won't be necessary for hosting the repository used for pull
requests on nongnu.org.

Re: pull requests

[Dmitry Gutov]

On 30.03.2020 19:09, Eli Zaretskii wrote:
>> This discussion was revived when Richard said that pull requests should
>> be "hidden". Which is a novel request.
> AFIU, that won't be necessary for hosting the repository used for pull
> requests on nongnu.org.

That only brings further questions.

How would that even work? AFAIK none of Github clones (Gitlab, etc) 
support pull requests between separate installations. And it's 
non-trivial to implement (and possibly harder to justify to Gitlab's 
developers).

And without the "standard" PR automation we're back to the current state 
of affairs: either send patches over email, or, okay, links to external 
repositories and branches (you can recall yourself how often that happens).

More importantly: suppose we have a separate Gitlab installation in 
nongnu.org. Who's going to be able to create new branches there? There 
same current pool of Emacs developers? A separate list of people who ask 
for access afterwards? Everyone? If it's the first option, I don't see 
why we'd go to such great lengths at all: anyone who wanted to create 
"bad" branches, can do so now in the current repo.

Re: pull requests

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 30 Mar 2020 20:06:27 +0300
> Cc: cpitclaudel@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>  rms@gnu.org
> 
> That only brings further questions.
> 
> How would that even work?

I don't know.  Part of the job is to figure this out and set up
whatever is necessary for it to work.  The FSF personnel who oversee
Savannah should be able to help some.

> More importantly: suppose we have a separate Gitlab installation in 
> nongnu.org. Who's going to be able to create new branches there?

Should be possible for anyone, once this is separate from the official
GNU repository and on a separate server.

Re: pull requests

[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 have never seen what a pull request is like to use.  I do not use
the systems which support them.  In trying to think about their
implications, I have to go by the descriptions people have sent me
in this discussion.

Unfortunately, the descriptions I've reaceived seen to conflict.
Perhaps people were describing different ways that different projects
or different platforms handle pull requests, but I did not know that
when I read them.

Also, they are written to be read by people who have used pull
requests and basically understand them, which I do not.  As a result,
I have trouble making sense of them.

I want to make sure we avoid results that would undermine the GNU
Project's moral and political position.  For instance, the result of
distributing something that we say is an injustice and should not
exist at all.

Just what is required for this, in practical terms, depends on how we
would implement the pull requests.  Some methods don't have a
problem; some do.

Could people figure out which different approaches they
are considering, then tell me how those approaches work?

-- 
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: pull requests

[Dmitry Gutov]

Hi Richard,

Sorry for the late reply. I'll try to make a good description.

On 02.04.2020 05:39, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
> I have never seen what a pull request is like to use.  I do not use
> the systems which support them.  In trying to think about their
> implications, I have to go by the descriptions people have sent me
> in this discussion.
> 
> Unfortunately, the descriptions I've reaceived seen to conflict.
> Perhaps people were describing different ways that different projects
> or different platforms handle pull requests, but I did not know that
> when I read them.

AFAIK, there are basically two different things that are called a "pull 
request".

The first is basically an email with details about the repository and 
the branch you want code "pulled" from. There are more details here: 
https://www.kernel.org/doc/html/latest/maintainer/pull-requests.html, 
but this is largely irrelevant to this discussion because a) we can do 
this already (and don't need any help with that), b) our developers and 
contributors don't use this approach. So it's not what we've been 
discussing.

The second one (which is what we're considering) has been popularized by 
the proprietary code forge called GitHub. In there, users can make 
'forks' of the original repository, where a fork is basically a copy of 
the original repository that belongs to the user's account (and its URL 
has the user's username in it). The said user can create a new branch, 
push some changesets into it, and then propose the said branch to the 
original repository and its developers for merging. By creating a "pull 
request".

It's a "thing": Github, as well as similar forges such as Gitlab, have a 
dedicated type of issue (*) that's called a "pull request". It has all 
the features of an "issue" (which generally means people can leave 
comments in it), as well as extra features: it shows the author, the 
source branch, a multi-line description that the author usually has to 
fill, the proposed commits, it can show the combined diff of those 
commits, users can leave comments associated with individual lines of 
that diff (and the UI displays that neatly), they can lead threaded 
discussions on said commits (which get semi-hidden as soon as the 
related code has changed), and the PR tracks the source branch closely, 
so as soon as the user pushes some new changes to the branch, the 
information in the PR updates automatically. The PR web page can show 
the status of the CI build for the proposed branch. The main 
repository's maintainers can merge the PR with just a couple of clicks 
with the mouse (this works best with small contributions). There are 
other features.

Overall, a lot of developers are used to this workflow and would never 
choose patch submission over email. Of course, not everybody. Some 
people just don't like web interfaces, for example.

(*) Issues are basically bug reports, but people can use them for 
discussions, support questions, and so on.

Re: pull requests

[Stefan Monnier]

>> I don't follow: in all likelihood, that URL that A sends to B points
>> to the web interface (at least, that's what I saw in 100% of the
>> cases with github and gitlab).
> IME, that URL is both for the Web interface and for accessing the
> repository.  If you point a browser there, you get the Web interface; if you
> clone from that URL, you get the code.

This dual-use only applies to the URL of a whole Git repository.
Not for branches or pull requests.

If using "nongnu.org" is considered sufficient, then we could also have
a similar marker in the URL of non-official repositories
(i.e. personal repositories used to upload pull requests, I guess).

Of course, the need to have your own fork of a repository on github.com
in order to submit a pull request on some other repository on github.com
is a serious deficiency, IMO, and if we could use a system that does not
impose such a constraint it would be much better (both for me as a user
and for the FSF in terms of the resources they'd need to host that
system).


        Stefan

Re: pull requests

[Dmitry Gutov]

On 30.03.2020 16:43, Stefan Monnier wrote:
> Of course, the need to have your own fork of a repository on github.com
> in order to submit a pull request on some other repository on github.com
> is a serious deficiency

How else would you do/implement that? Without having push access to the 
target repository, of course.

I think Github's solution is pretty elegant. Of course, it works as well 
as it does because forks are copy-on-write under the covers. Unlike in 
Gitlab currently.

Re: pull requests

[Stefan Monnier]

>> Of course, the need to have your own fork of a repository on github.com
>> in order to submit a pull request on some other repository on github.com
>> is a serious deficiency
> How else would you do/implement that?

I'd have the pull-request-submitter provide a URL to a Git branch.
That branch would then be fetched and added to the repository as
`refs/pull/<NB>` or something like that.

> Without having push access to the target repository, of course.

That would provide push access but not to the whole repository: only to
`refs/pull/<NB>`.


        Stefan

Re: pull requests

[Dmitry Gutov]

On 30.03.2020 20:20, Stefan Monnier wrote:
> I'd have the pull-request-submitter provide a URL to a Git branch.
> That branch would then be fetched and added to the repository as
> `refs/pull/<NB>` or something like that.

That might work. Along with a "Refresh" button to update the PR contents 
after the external branch has received some changes.

I've never seen this implemented anywhere, though.

Re: pull requests

[조성빈]

> 2020. 3. 30. 오후 12:39, Richard Stallman <rms@gnu.org> 작성:
> 
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>>> That is a statement of intentions, not facts.  Emacs developers
>>> would know those intentions, but other Emacs users might have no
>>> idea about them.
> 
>> That's why we have forges, with self-explanatory web interfaces and even 
>> integrated help for new users.
> 
> That would inform some users, those who do certain things.  But in the
> scenario I pointed at, the users would not do those things, so they
> would not get the information.
> 
> This is the scenario I pointed at:
> 
>   Suppose A sends B a URL pointing to a branch with non-installed
>   patches.  If A doesn't warn B, or if A is too terse and does not make the
>   point clear, B will not know it is non-installed.  B will only see
>   that it is in the standard GNU Emacs repo.

If GNU hosts a forge with PR support working similar to GitHub or GitLab, the URL won’t point to the standard GNU Emacs repo, it will point to a custom fork (which IMHO nobody can really confuse). 

For example, let’s say that a Git Forge with a PR model is running on nongnu.org (for instance). The canonical Emacs repo (running by an organization account named ‘gnu’) will be accessible from the URL nongnu.org/gnu/emacs.git. If one wants to make a change on Emacs, one can make an account on nongnu.org (let’s say ‘pcr910303’), press the Fork button from the gnu/emacs repo, and the fork will be accessible from the URL nongnu.org/pcr910303/emacs.git. If I want to merge some code into the canonical emacs repo (with using the web UI), I can push some commits to pcr910303/emacs, go to nongnu.org/gnu/emacs and make a PR across repos. If one wants to check out the change, one can pull from ‘nongnu.org/pcr910303/emacs.git’. The URL clearly indicates that it’s not the official repo, hence it won’t be a problem.

Also, currently non-installed patches can be downloaded from the GNU Emacs mailing list from the URL lists.gnu.org. If the user uses something like curl to download the patch, one will not know whether it’s installed or not. I think it won’t be that different.

>> 99% of the users who would be looking at them, would be doing so through 
>> the web interface of the force software.
> 
> In that scenario, large numbers of users might not go through that interface.
> They might not even know there is a web interface.
> 
>> When you were talking about hiding PRs from non-developers, you meant 
>> hiding in the web interface, right? 
> 
> I mean blocking access to them _in the repo_, for all interfaces.  If
> you're not logged in as a member of the project, you would not be
> allowed to check out that branch by running git.
> 
>> Because it would be hard to hide 
>> them in the mailing lists,
> 
> The mailing list is a different kind issue.  If you abstract away
> the practical differences, you might think it is the same; but those
> practicalities change everything, in this case.
> 
> I am not talking about adding security where we have done ok without
> it.  My aim is to limit the possible new danger from the change that
> you are asking for.
> 
> I know that many other projects use pull requests and are happy with them.
> But those projects do not share our nontechnical overriding goals:
> 
> * Do not distribute nonfree software.
> * Do not publish text that recommends nonfree software.
> * For some projects, do not include code without legal papers.
> 
> We have a system for avoiding this: the package maintainers decide
> what to install, and they check these criteria before installing
> anything.  (See the GNU Coding Standards and GNU Maintainer's Guide.)
> 
> Keeping uninstalled code in the same repo as the installed code makes
> it too easy to overlook the difference between them.
> 
>> But if we manage to support merge requests from contributors without 
>> commit access, and do it without external repositories, we could just as 
>> well mandate that all such branches have names prefixed with 
>> "merge-request/", and that will avoid any confusion.
> 
> I am not convinced it would work "just as well."  But that idea is
> worth thinking about.  we need to think _not only_ about how we would
> intend this facility to be used, but also how to make sure it is not
> misused.
> 
> How, in practice, would we ensure that all installation proposals
> have a name starting with 'merge-request/'?
> 
> How would we find out if many users begin accessing a branch whose
> name begins with 'merge-request/'?
> 
> How would we find out if one is created with a name that doesn't
> start with that prefix?
> 
> Could we arrange that those branches start out accessible only to
> maintainers, then become generally accessible when a maintainer says
> "Make this accessible"?
> 
> 
> 
> -- 
> 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: pull requests

[Dmitry Gutov]

On 30.03.2020 11:25, 조성빈 wrote:
> If I want to merge some code into the canonical emacs repo (with using the web UI), I can push some commits to pcr910303/emacs, go to nongnu.org/gnu/emacs and make a PR across repos. If one wants to check out the change, one can pull from ‘nongnu.org/pcr910303/emacs.git’. The URL clearly indicates that it’s not the official repo, hence it won’t be a problem.

I don't think GitLab supports PRs across separate installations, does it?

Re: pull requests

[Eli Zaretskii]

> From: 조성빈 <pcr910303@icloud.com>
> Date: Mon, 30 Mar 2020 17:25:26 +0900
> Cc: Dmitry Gutov <dgutov@yandex.ru>, eliz@gnu.org, cpitclaudel@gmail.com,
>  Emacs-devel@gnu.org
> 
> >   Suppose A sends B a URL pointing to a branch with non-installed
> >   patches.  If A doesn't warn B, or if A is too terse and does not make the
> >   point clear, B will not know it is non-installed.  B will only see
> >   that it is in the standard GNU Emacs repo.
> 
> If GNU hosts a forge with PR support working similar to GitHub or GitLab, the URL won’t point to the standard GNU Emacs repo, it will point to a custom fork (which IMHO nobody can really confuse). 

I think Dmitry was arguing for having this in the Emacs repository.
Having a separate hosting server, especially one that is on
SOMETHING.nongnu.org, was already agreed to, so no reason to argue
about that.

Re: pull requests

[Dmitry Gutov]

On 30.03.2020 06:38, Richard Stallman wrote:

> This is the scenario I pointed at:
> 
>     Suppose A sends B a URL pointing to a branch with non-installed
>     patches.  If A doesn't warn B, or if A is too terse and does not make the
>     point clear, B will not know it is non-installed.  B will only see
>     that it is in the standard GNU Emacs repo.

It's hard to optimize for people willing to misunderstand things. At 
some point we have to just draw the line.

>    > 99% of the users who would be looking at them, would be doing so through
>    > the web interface of the force software.
> 
> In that scenario, large numbers of users might not go through that interface.
> They might not even know there is a web interface.
> 
>    > When you were talking about hiding PRs from non-developers, you meant
>    > hiding in the web interface, right?
> 
> I mean blocking access to them _in the repo_, for all interfaces.  If
> you're not logged in as a member of the project, you would not be
> allowed to check out that branch by running git.

I mean... if it's not too hard to implement, that would be okay with me, 
as long as the web UI shows the PRs even to unauthenticated users.

The latter is not a hard necessity, of course, but I believe that more 
transparency in Emacs's development process, the ongoing discussions, 
etc, via the "forge" interface would benefit it a lot. Users will 
comment more, follow the development of new features more, and will thus 
be encouraged to submit more patches themselves.

> 					Because it would be hard to hide
>    > them in the mailing lists,
> 
> The mailing list is a different kind issue.  If you abstract away
> the practical differences, you might think it is the same; but those
> practicalities change everything, in this case.
> 
> I am not talking about adding security where we have done ok without
> it.  My aim is to limit the possible new danger from the change that
> you are asking for.

To be clear, we already have branches in the repo which 200+ people can 
push to. If we're not worried about them, are we worried only about 
branches created by "unauthenticated" users?

Being able to facilitate that is a challenge in itself (+).

> Keeping uninstalled code in the same repo as the installed code makes
> it too easy to overlook the difference between them.

One way to solve that would be to use a forge software that makes it 
easy to have multiple repositories (one per user, even), with fast 
"forking" action. Gitlab is not there, alas.

>    > But if we manage to support merge requests from contributors without
>    > commit access, and do it without external repositories, we could just as
>    > well mandate that all such branches have names prefixed with
>    > "merge-request/", and that will avoid any confusion.
> 
> I am not convinced it would work "just as well."  But that idea is
> worth thinking about.  we need to think _not only_ about how we would
> intend this facility to be used, but also how to make sure it is not
> misused.
> 
> How, in practice, would we ensure that all installation proposals
> have a name starting with 'merge-request/'?

If we manage to solve the problem (+) above, we can include that as a 
part of the solution. Maybe the unauthenticated users would send 
patchsets over email, and whatever code will be set up to handle that, 
could enforce whatever branch naming scheme that we choose.

> How would we find out if many users begin accessing a branch whose
> name begins with 'merge-request/'?

Savannah admins might help with that. Some HTTPS proxy, maybe.

> How would we find out if one is created with a name that doesn't
> start with that prefix?

Is that question different from the previous-previous one?

> Could we arrange that those branches start out accessible only to
> maintainers, then become generally accessible when a maintainer says
> "Make this accessible"?

You seem to be trying to combine the two requirements together now, to 
make an even more difficult requirement.

But to answer that question: the forge software, or the Git server 
software, or a combination of them, have to support that.

Re: pull requests

[Clément Pit-Claudel]

On 27/03/2020 11.21, Eli Zaretskii wrote:
> So we are supposed to keep pointers to those sites, and use them?
> How do we know which site holds what relevant discussions? who will 
> remember that several years after the discussion took place?

Don't we have the same issue with debbugs and mailing lists?  At the moment we put links to bugs.gnu.org, emacs-devel, help-gnu-emacs, as well as the bug trackers and mailing lists of various other projets, when relevant).  Here we would put links to pull request numbers, likely prefixed with some identifier; maybe something like gitlab:57?

> And what if the tracker that hosted the discussion goes dark (e.g.,
> because the person who submitted the patch is no longer keeping the
> branch, 

That's not how it works: comments are attached to code fragments, like in a patch, so they don't go away if the branch is deleted.  Just like patches sent by email.

> or simply because the hosting service is discontinued?

I expect we would self-host, like debian and gnome do with gitlab, right? So if we decided to discontinue the service (i.e. migrate to another platform) we would need to migrate our issues as well.

> We must have all these archives in a single place, which we can 
> control and which we can ensure continues to be available for years
> to come.

Definitely: that's why we imported old history when we migrated to git.  Same for bug tracking or pull requests: if we move to a different service, we'd want to export them.

Clément.

Re: pull requests

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Fri, 27 Mar 2020 12:39:36 -0400
> 
> On 27/03/2020 11.21, Eli Zaretskii wrote:
> > So we are supposed to keep pointers to those sites, and use them?
> > How do we know which site holds what relevant discussions? who will 
> > remember that several years after the discussion took place?
> 
> Don't we have the same issue with debbugs and mailing lists?  At the moment we put links to bugs.gnu.org, emacs-devel, help-gnu-emacs, as well as the bug trackers and mailing lists of various other projets, when relevant).  Here we would put links to pull request numbers, likely prefixed with some identifier; maybe something like gitlab:57?

We now have the bug tracker and a couple of mailing lists (which are
really a minority, as most bugs are reported to debbugs).  The
proposal to which I was responding was to put the patches on random
remote branches out there, not on a single server.  That would make
the problem unmanageable.

> I expect we would self-host, like debian and gnome do with gitlab, right? So if we decided to discontinue the service (i.e. migrate to another platform) we would need to migrate our issues as well.

Like Dmitry, you are responding to a proposal different from what was
made, to which I posted my comments.  The proposal was NOT to have a
single server.

Re: pull requests

[Stefan Monnier]

>> More importantly, given that I did a review
>> of such a remote branch, how do I communicate my comments so that they
>> are recorded for posterity?  Probably by email, so that doesn't seem
>> to solve the main problem of avoiding email in the patch submission
>> and review workflow.
>
> Assuming you use the web UI, you can typically attach comments to code regions.

I never use those web UIs when reviewing Git branches.
Instead, I fetch those branches with Git and then review them locally
(thank god!).

> Pros over email reviews include the fact that the comments remain attached
> to the code even after the patch is updated (so if the original author
> updates an unrelated section of the patch the comments don't disappear) and
> the fact that you get to see the full code, rather than just the patch.
>
> Cons include inferior text-editing capabilities, and inferior code browsing
> capabilities compared to applying the patch and browsing around in Emacs
> (but you can always checkout the branch, which I find nicer than applying
> patches by hand anyway).

My foggy memory says there was tool (developed by Google, maybe?) that
standardized a representation of annotations to store inside the Git
repository, so you could get both benefits (i.e. write your annotations
locally with the tool you like and then store them for posterity
attached to the code).

I can't remember its name any more (and I never used it).


        Stefan

Re: pull requests

[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 remember the precise conclusions last year, but ISTR I
  > > concluded that any pull requests on a GNU forge must be visible _only_
  > > to the developers of the package.

  > IIRC, the most important, at least IMO, conclusion was that we should
  > host such services on savannah.nongnu.org, so that any code in those
  > pull requests is not considered to "belong to GNU".

Yes, that is right.  We could put those pull requests somewhere other
than the Emacs repo (for instance, savannah.nongnu.org, or we could
put them in the Emacs repo but make them accessible only to the Emacs
developers.


-- 
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: ELPA: where is chess developed?

[Stefan Monnier]

> I believe I've the time and taste to get them back in sync,

That would be awesome.  Even better if you can get Mario and John to
help out (in case there are non-obvious decisions to make) and, more
importantly, if the result can be merged back into John's repository.

> but I think I need push access to savannah, of which I've been denied
> in the past (and perhaps with good reason).

In the mean time, if you can point me to a publicly readable Git
repository of yours, I can take care of pushing it to elpa.git.


        Stefan

Re: ELPA: where is chess developed?

[Mario Lang]

"John Wiegley" <johnw@gnu.org> writes:

>>>>>> "JH" == Jack Hill <jackhill@jackhill.us> writes:
>
> JH> What's going on here? Did the project fork and there are two development
> JH> streams going forward? Did the aspiration to develop chess in the ELPA
> JH> repository fail, and we should switch back to jwiegley/emacs-chess as
> JH> upstream? If I package this for my distribution, which one should I use?
>
> I believe that Mario Lang is currently the most active developer, and that he
> organized releases to ELPA. Whether that's the home seat of development or
> not, I would ask of him. Mario?

Well, its hard to define a "home seat" with distributed VCSs...
Indeed, I pushed for chess.el to become a part of ELPA around 2014.
That was when I last went on a crusade to eliminate as many small bugs
as I could find.

I informed John about this move, actually several times.

However, we never actively removed any other repos, so apparently
johnwiegley/emacs-chess from github accumulated some stuff over time
which IMO always should have been merged to ELPA.

I guess its my fault that I didn't manually track these patches.
However, I sort of assumed John would know that he is splitting history
when accepting PRs on github.

-- 
CYa,
  ⡍⠁⠗⠊⠕