caml-list - the Caml user's mailing list
 help / Atom feed
From: Gabriel Scherer <gabriel.scherer@gmail.com>
To: orbifx <fox@orbitalfox.eu>
Cc: caml users <caml-list@inria.fr>
Subject: Re: [Caml-list] Announcing Sek, an efficient implementation of sequences
Date: Sat, 4 Apr 2020 15:56:58 +0200
Message-ID: <CAPFanBFyrip=Eo0FXjgc9dF3hZ7dgyKiQODrPBAc2YovmDQHcg@mail.gmail.com> (raw)
In-Reply-To: <35914488-1401-ccb3-50d8-5014f2aa1191@orbitalfox.eu>

[-- 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 --]

  reply index

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-04 10:11 François Pottier
2020-04-04 13:18 ` Gabriel Scherer
2020-04-04 13:29   ` orbifx
2020-04-04 13:57     ` Gabriel Scherer [this message]
2020-04-04 14:04       ` orbifx
2020-04-07 22:07       ` Gerd Stolpmann
2020-04-05 11:36   ` François Pottier

Reply instructions:

You may reply publically 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='CAPFanBFyrip=Eo0FXjgc9dF3hZ7dgyKiQODrPBAc2YovmDQHcg@mail.gmail.com' \
    --to=gabriel.scherer@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=fox@orbitalfox.eu \
    /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

caml-list - the Caml user's mailing list

Archives are clonable: git clone --mirror https://inbox.ocaml.org/caml-list

AGPL code for this site: git clone https://public-inbox.org/ public-inbox