From: Philip Kaludercic <philipk@posteo.net>
To: Uwe Brauer <oub@mat.ucm.es>
Cc: Andrea Corallo <acorallo@gnu.org>, <emacs-devel@gnu.org>
Subject: Re: having emacs-matlab in ELPA, finally. FSF paper signed
Date: Mon, 12 Aug 2024 15:06:47 +0000 [thread overview]
Message-ID: <87le1193w8.fsf@posteo.net> (raw)
In-Reply-To: <87sev9zt31.fsf@mat.ucm.es> (Uwe Brauer's message of "Mon, 12 Aug 2024 16:58:10 +0200")
Uwe Brauer <oub@mat.ucm.es> writes:
>> Uwe Brauer <oub@mat.ucm.es> writes:
>
>> I am afraid I don't understand what you are trying to say here. It is
>> true that you should check if new contributors have signed the FSF CA,
>> but how does that related to Git branches?
>
> Sorry for not having explained this better. Once we have moved to github
> (which I hoped to have done already),
BTW, I forgot to mention that I can also recommend Codeberg, if it is
just the UI you care about.
> there are two scenarios
>
> 1. We proceed as before, that is around 4 authors, all of them
> having signed the FSF paper, continue to contribute.
>
> 2. Out of sudden, because it is github and a people love pull
> requests, a lot of contributions pop up, maybe from people
> working for matlab, or for any other reasons. These contributions
> might introduce new sexy features or bug fixes or both, but the
> authors are somehow lazy to sign the FSF papers (it was quite a
> bit of ordeal to have all contributors signed). In that scenario,
> it might be a good idea to have 2 branches,
>
> 1. one for commits with authos having signed the FSF papers
>
> 2. One for commits with new contributions but with non-FSF
> authors.
Hmm, I have never heard of this kind of a model, usually a pull request
would just stay open until the person has signed the documents. The
main issue I'd anticipate is that it would become difficult to keep an
overview of what was contributed by someone having signed the CA and
not, causing fragmentation and a higher burden of maintenance.
>
> From experience it is best to be prepared. I know git is flexible: I can
> create, rename and delete branches, but because git is so flexible the
> process is not failsafe, name-rev does not always assign to a commit the
> correct branch, which makes me nervous (being a mercurial user).
>
>
>> Disregard this, I seem to have attached the wrong diff.
>
> Ok.
>
>> OK, just ping me when you think the cleanup process is done, and I can
>> tell you if anything remains to be done before adding the package.
>
> Hopefully soon.
--
Philip Kaludercic on peregrine
next prev parent reply other threads:[~2024-08-12 15:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-02 12:45 having emacs-matlab in ELPA, finally. FSF paper signed Uwe Brauer
2024-08-06 21:55 ` Andrea Corallo
2024-08-07 17:03 ` Uwe Brauer
2024-08-07 17:54 ` Andrea Corallo
2024-08-12 11:20 ` Philip Kaludercic
2024-08-12 11:33 ` Andreas Schwab
2024-08-12 11:38 ` Philip Kaludercic
2024-08-12 12:16 ` Uwe Brauer
2024-08-12 12:29 ` Philip Kaludercic
2024-08-12 14:58 ` Uwe Brauer
2024-08-12 15:06 ` Philip Kaludercic [this message]
2024-08-12 15:17 ` Uwe Brauer
2024-08-12 16:11 ` Philip Kaludercic
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87le1193w8.fsf@posteo.net \
--to=philipk@posteo.net \
--cc=acorallo@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=oub@mat.ucm.es \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.