Re: Gitlab Migration

[Dmitry Gutov <dgutov@yandex.ru>]

On 28.08.2021 09:00, Eli Zaretskii wrote:
>> Cc: Daniel Fleischer <danflscr@gmail.com>, philipk@posteo.net,
>>   emacs-devel@gnu.org
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Sat, 28 Aug 2021 00:09:41 +0300
>>
>>   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.
> 
> That sounds worrisome.
> 
> Can you tell how did you see what SourceHut offers in this department,
> so others (myself included) could have a look?  I cannot find any
> documentation of the features.

I used my web browser, mostly following the links others submitted in 
this discussion (and then followed some links from there), also did some 
educated guessing (and turned out to be wrong on the subject of CI 
indicators and links to builds).

The video Drew posted yesterday (see the response to it I sent just now) 
has also been illuminating.

I haven't looked too deeply or tried to work with it personally, so my 
impressions are of course superficial and biased. Perhaps somebody wants 
to create a test project on sr.ht and invite a bunch of us to 
collaborate? Or set up a private installation like emba.gnu.org, with 
the same end goal.

>> Of course, it should still be a significant step forward compared to the
>> current situation.
> 
> Can you elaborate why you think so, given the lack of the above
> features?

It seems to provide a nicer/better bug tracker and mailing list archive 
viewers than the ones we already have. With unified views, better 
searching, tagging and perhaps even an ability to write messages from 
the browser (which is certain to appeal to some newcomers). Maybe also 
features like subscribe/unsubscribe to a discussion, though that looks 
less certain.

We have generally routed around those problems (by doing extra manual 
work, usually; or asking others to do it), but that haven't made them go 
away. E.g. recall at the beginning of this thread you suggested the 
author would do a search for the previous thread on the subject and then 
find the gitlab issue there. I'm guessing it was, at least in part, due 
to the search on lists.gnu.org being not that great.

Of course, whether this promise will hold up (with good performance and 
few bugs) remain to be seen, but Drew has a good track record.

Overall, if we finally accept that neither UI familiarity (for new 
users) nor workflow familiarity (for new contributors) are a priority 
for the Emacs project, this might a reasonable option to migrate to. I 
just wonder whether we'd have to do another migration in 5-10 years, 
with the natural change in Emacs contributor base.