help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why is Elisp slow?


From: Óscar Fuentes
Subject: Re: Why is Elisp slow?
Date: Sun, 05 May 2019 15:19:03 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

"Paul W. Rankin" <hello@paulwrankin.com> writes:

>> For the developers it is also easier to join to those projects
>> because they are hosted on Github/gitlab with a more familiar
>> workflow and interface, no copyright procedure, no mailing list....
>> and everything in the same please and integrate with a fork based
>> workflow. You can see where I'm going right?
>
> If a possible contributor has cloned a project repository to their own
> machine and has made some changes, the fork-based workflow requires
> that they: create an account at the origin project's GitHub or GitLab
> (or the project's GitLab instance),

This is an one-off task.

> create a forked repository there,

Same.

> add the fork as a remote on their machine,

Same.

> push the changes, then open a pull request.

Which, in my experience, takes half a minute with the Github UI and
possibly less with Magit's Github plugin.

> Once you use a git send-email workflow, this fork-based workflow will
> seem convoluted and unnecessarily centralised. All a contributor need
> do is clone the project repository, commit some changes then run:
>
>    git send-email HEAD^

You skipped over quite a few issues here. Plus, a branch is easy to
access, in case someone wishes to grab the changes, while fishing mails
on a mailing list requires more setup and constant attention.

> And send the email to the project's owner/mailing list. No account
> creation necessary. Check out:
>
>    https://git-send-email.io/

Yes, that explains the job on a detailed way, and you can see that it is
not as simple as you pretend. Plus, that's the setup for sending
changes, no mention about how to grab them from the ml.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]