Re: Gitlab Migration

[Theodor Thornhill]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 28.08.2021 00:17, Theodor Thornhill wrote:
>
>>>   From what I have seen of it, it's email-first, and far from "full and
>>> convenient support for ... web".
>>>
>>> For example, those quality-of-life features that Gitlab has in the
>>> browser which I previously figured would be difficult to translate  to
>>> email (the code review workflow, with inline comments and updates from
>>> the branch; automatically updated CI indicators and links to builds;
>>> editing of messages) are predictably absent.
>> 
>> This isn't really true though.
>
> It seems substantially true.
>
>> There definitely are links to builds and
>
> There's no such examples on the home page (and it does have a link to a 
> page supposed to resemble a code review). If you have a better link, 
> please share.
>

https://lists.sr.ht/~technomancy/fennel/patches/24386

This shows both a build that succeeded and an inline comment.  More
complicated stuff is likely still missing, but this seems to address
part of what you were referring to, doesn't it?  There's also examples
where faling builds sends out notifications etc.  I can try to find some
of those, but that will be shooting in the dark until I find one...

>> inline comments.
>
> Inline comments like quoting parts of an attached patch inline in an 
> email, which we've been doing for decades in emacs-devel? That's not 
> even close to a dedicated code review UI.
>
>> Though I agree on parts of this.  One missing thing as
>> I see it is the updated patch. You need to find the latest patches, and
>> it won't update as in GitHub when you add another "oops" commit.
>
> The review UI would need to be tied to a particular branch, instead of 
> some file attachments. And happen not in a email client, but either in a 
> browser, or perhaps some re-implementation of the same UI inside Emacs.
>

Yeah, I agree this is missing, at least if we're not willing to accept
that this might not be the number one thing to need before migrating.


>>> Of course, it should still be a significant step forward compared to the
>>> current situation.
>> 
>> Yeah.  One might also think that some contributions could trickle down
>> to sourcehut itself when emacs workflow settles, so the "github way" of
>> contributing could get a little love?
>
> I doubt that: since the system is email-first, it would likely be hard 
> to promote/upstream features that don't translate well to email. Even if 
> someone writes an Emacs UI for them. Does Drew use Emacs?

You might be correct about this.  No, he is a vim user, and seems a
little negative towards emacs, as far as I can tell.

Theodor