unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: phillip.lord@russet.org.uk (Phillip Lord)
To: Richard Stallman <rms@gnu.org>
Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
Subject: Re: In Support of ELPA
Date: Mon, 17 Jul 2017 15:05:37 +0100	[thread overview]
Message-ID: <87fudvma4u.fsf@russet.org.uk> (raw)
In-Reply-To: <E1dWYhr-0006SE-6N@fencepost.gnu.org> (Richard Stallman's message of "Sat, 15 Jul 2017 21:50:47 -0400")

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 difference is whether the Emacs maintainers have write access
>   > > to those sources in their main repository.
>
>   > Personally, I think this is not necessary. The Emacs maintainers can use
>   > PRs if they need to.
>
> We need to have write access directly so that we can install changes
> directly without depending on anyone else.  But not solely write access.
> We need administrative access too.  When other people send PRs, we need
> to be able to receive them.

I don't think this is necessary, not with a distributed version control
system. If we have a package developed elsewhere, and ELPA has a local
clone (either as a repo, or a branch), then any PRs from others could be
resent to the downstream, and likewise any changes for Emacs
maintainers.

On the occasion that a change really needs to be installed locally
without depending on any one else, then you could just do
this. Subsequent pulls from downstream to ELPA would now fail, as they
would be non-fast-forward; someone would have to sort this out
manually. But this is the situation anyway, if there is a downstream
copy of the source code; changes made on ELPA have to be incorporated
back into the mainline.

What sort of changes do you envisage where a PR is not enough? How often
do these happen?

Phil




  reply	other threads:[~2017-07-17 14:05 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-11 21:46 In Support of ELPA Phillip Lord
2017-07-11 22:37 ` Stefan Monnier
2017-07-12 13:30   ` Ted Zlatanov
2017-07-13 12:23     ` Richard Stallman
2017-07-13 15:05       ` Ted Zlatanov
2017-07-13 22:02         ` Phillip Lord
2017-07-13 16:15   ` Phillip Lord
2017-07-14  1:20     ` Richard Stallman
2017-07-14 10:02       ` Phillip Lord
2017-07-16  1:50         ` Richard Stallman
2017-07-17 14:05           ` Phillip Lord [this message]
2017-07-14  2:12     ` Stefan Monnier
2017-07-14  6:48       ` Thien-Thi Nguyen
2017-07-15  1:35         ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87fudvma4u.fsf@russet.org.uk \
    --to=phillip.lord@russet.org.uk \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=rms@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).