>> May I know why instead of an RFE for a migration to have those
>> features, haven't you already set up one much like what a GNU/Linux
>> distro usually sets up to collect things pending upstream intake?
>
>
> I'm sorry but I don't understand this question. We are talking about adding a gitlab workflow to the existing mailing list workflow so that gitlab/github users are happier and more prone to contributing. I don't understand what you are asking about this topic.
You gave the following links as examples that I suppose are intended
to strengthen your argument:
> https://github.com/bbatsov/projectile/pull/1386
> https://github.com/moby/moby/pull/38823
> https://github.com/Silex/docker-emacs/pull/24
AFAIK, those three links have nothing to do with the things that are
discussed in this mailing list, which mostly concerns the Emacs core.
Yes, they are examples about how things are done elsewhere, to illustrate how things could be if we added the gitlab workflow. I suspect that maybe many people here don't really realise what the gitlab workflow is or how it looks, so I wanted to show examples.
The gitlab workflow that is proposed in this thread, however, is
concerned with the things that are discussed in this mailing list
(Emacs core). Hence, I expect that the links given as examples would
be about pull requests for things related to Emacs core that had not
been taken upstream by those in this mailing list.
Well I cannot show examples of something that does not exist, you cannot do github/gitlab pull requests to the emacs core, you can only go through the mailing list (or other non-pull-request means).
>> Additionally, if some packages are better maintained external to the
>> core Emacs, why not let them be so rather than trying to bringing them
>> contributing directly to the core?
>
>
> Again I don't understand what external packages have to do with the topic. We are not talking about including external packages to core Emacs.
No, we are not talking about including external packages. Hence, do
you have examples that support your argument that there are people out
there who would contribute to the Emacs core provided that the Emacs
core development adopts the gitlab model?
Again I cannot have examples of something that does not exist.
As I said earlier, it's possible that adding the gitlab workflow would yield 0 additional contributors, the only way to know for sure would be to try it. Personnally I believe that at least for "typo fixes" and tiny changes you'd get more contributions, because proposing a change on the gitlab model is trivial (browse to the correct file, click "edit", edit the file in your browser, press "propose changes", done).
Anway, what I am sure of is that if the gitlab workflow was added there would be contributors on this ML (including me) that would use it instead of the mailing list workflow.
If the Emacs maintainers decide not to add the gitlab workflow it's fine by me, I'm not on a quest to convince everyone. I think you should, but I understand if you don't.
Kind regards,
Philippe