Re: [Caml-list] Announcing Sek, an efficient implementation of sequences

[Gabriel Scherer <gabriel.scherer@gmail.com>]

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

I don't have strong opinion against mail-based contributions (I suspect
they are perceived as less beginner-friendly by newer contributors who have
grown up in the web-interface-based-world, but that's a discussion for
another time). The problem here is that a select group of contributors can
use a certain contribution procedure (here: Merge Requests), and external
contributors have to use a different approach (email or issue-based), or
ask permission to use the first-group's approach. In this setting the
second approach is *objectively* second-class, and this difference
objectively sucks.

There are other places that host Gitlab instances without this restriction.

The restriction is originally caused by design issues in Gitlab, which ties
"sending a Merge Request" with "having a fork on the same server" (which
paranoid sysadmins want to forbid to public users as it may create
resource-consumption issues). Gitlab is working on making it possible to
open a Merge Request by just sending a patch (
https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html#new-merge-request-by-email-core-only
), and maybe some other git-host server will rise to visibility with a
better federation story ( https://sourcehut.org/ ?).

(If you are interested in hosting a web platform for git hosting, I'm told
that gitea ( https://gitea.io/ ) is much easier to deploy than Gitlab.)

On Sat, Apr 4, 2020 at 3:30 PM orbifx <fox@orbitalfox.eu> wrote:

> On 04/04/2020 14:17, Gabriel Scherer wrote:
> > 1. gitlab.inria.fr <http://gitlab.inria.fr> makes it difficult for
> non-INRIA people to contribute (they cannot open a pull/merge request).
>
> Only for those who don't know how to contribute without "opening" a pull
> request. Which is otherwise as simple as sending a message with: here is my
> repo URL, please pull; or here is my patch attachment.
>
> > It is a mistake to use it for publicly-distributed software.
>
> I think not. I find it positively refreshing to see something outwith
> Gitlab's dominance. So it's a matter of opinion.
>
>

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