GitLab feature request compared with SourceHut (was: Re: Gitlab Migration)

[Sean Whitton <spwhitton@spwhitton.name>]

Hello,

On Fri 27 Aug 2021 at 10:08PM +03, Eli Zaretskii wrote:

>> Date: Fri, 27 Aug 2021 17:29:46 +0200
>> From: Theodor Thornhill <theo@thornhill.no>
>> CC: Eli Zaretskii <eliz@gnu.org>, Daniel Fleischer <danflscr@gmail.com>,
>>  philipk@posteo.net
>>
>> >There doesn't seem to be much movement on getting GitLab to support the
>> >features we want, so perhaps we should take a closer look at SourceHut
>> >instead.  Has anybody here done an evaluation of SourceHut to see
>> >whether it'd fit our requirements?
>> >
>>
>> We actually discussed it on this list with its creator, Drew DeVault last year:
>> https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg00534.html
>
> That was almost a year ago, and the discussion is thin on actual
> details.  Support for email-based workflow is a good start, and is one
> of the main requirements, but what about the GitLab/Github-like
> features? if they are missing or incomplete, we will be trading
> debbugs for something that is basically the same beast in a different
> wrapping.  And what about the other requirements we collected and
> documented in the GitLab issue about this?

For reference, the GitLab issue:
<https://gitlab.com/gitlab-org/gitlab/-/issues/28152>

> So, like Lars, I think it would help if someone could post an
> evaluation of SourceHut vs what we'd like to see, using the GitLab
> issue as the baseline.

Using the headers in the GitLab issue:

E-MAIL WORKFLOW

This is a given.  SourceHut is all about this.

Something to emphasise is that because SourceHut is e-mail first, rather
than a web platform with e-mail access tacked on, you don't have to
worry about how web forges can do things like ignoring everything in the
message after the first quoted portion, for example.  You don't find
yourself going on the website after replying by e-mail just to check
your text made it through.

REDUCE E-MAIL NOISE

There isn't much granularity regarding notifications, AFAICT.

SUBMITTING PATCHES BY E-MAIL

There's a web interface to prepare patch sets designed to be familiar
to web forge users.

OFFLINE REVIEW

Yes.

REVIEWING PATCHES BY E-MAIL

Yes.

MERGE REQUEST CREATION

Yes.

CODE SHOULD BE ACCOMPANIED BY DOCUMENTATION

Could be done with CI, like GitLab.

FORMATTING CODE COMMITS

Could be done with CI, like GitLab.

DIFF MAILING LIST

No special features for this, I believe.  You'd need a bot.

TRACEABILITY OF MERGE REQUESTS

The mailing list web interface keeps track of the status of series and
tags them "proposed", "applied" etc. and this is searchable.

CONTINUOUS INTEGRATION

Yes.

CLOSELY INTEGRATED BUGTRACKER

Looks a bit manual atm, but a big step up from debbugs because there is
both e-mail control and clickable buttons.

SPELLING & GRAMMAR CHECKING

Could be done with CI.

COPYRIGHT ASSIGNMENTS

Could be done with CI.

LICENSING

Yes.

INTEGRATION WITH SAVANNAH

SourceHut can currently use PAM users, so a Savannah/LDAP integration
along the same lines ought to be doable.

EMACS FRONTEND FOR BUG TRACKER

Doesn't exist yet :)

BUG REPORTING

Filing bugs and starting mailing list threads are both just a matter of
sending e-mails, so report-emacs-bug could do it.

-- 
Sean Whitton