Re: Gitlab Migration

[Clément Pit-Claudel]

On 8/26/21 3:04 PM, Eli Zaretskii wrote:
> It's actually the other way around, at least in some cases.  With
> patches that are emailed to me, I can fix some simple issues, such as
> commit log messages or simple typos, myself, before applying.  With
> merging via Web UI, I need to push another commit, which is a waste,
> and also breaks what should have been a single commit into several
> ones.  So with Web UI, I expect _more_ requests to contributors to get
> their act together, where automated fixups are impossible, because
> there's little I can do myself.

Oh, that's not how it typically works in the project that I contribute to (and 
that I maintain): the maintainer often makes small fixes before merging, amends 
the relevant commits with those changes, and then merge using "git merge".  Did 
I misunderstand?

>> - Responding to old bugs is easier.  With a mailing list, it's no 
>> necessarily clear what the process is.  Should I send a new message to the 
>> bug address? Or does it need the right response headers?  In that case 
>> should I download the mbox first and import it into my email client?
> 
> I think you see problems where there are none.  If you have an email
> message that belongs to a bug, reply to it; otherwise simply write to
> the bug address.  admin/notes/bugtracker explains this within its
> first dozen of lines.

This is in line with what I wrote above: there is a process that is specific to 
Emacs, and it requires reading a document that is specific to Emacs to get it 
right (and you have to find that document).

It's not that bad, really; just not super discoverable. 

> And it isn't like GitLab and similar platforms don't have similar
> issues

Oh, I agree (see my next sentence ^^).

>> I'm sure there are many other pros and cons, but email isn't necessarily 
>> particularly easy when you want to do more than send messages.
> 
> I realize that some people who want to contribute don't like emacs or
> are intimidated by it. 

I would be surprised if anyone who wants to contribute patches to Emacs doesn't 
like Emacs.  Maybe I'm misunderstanding what you're saying.

> That's an important reason to provide the UI
> to which they are more accustomed.  But let's not exaggerate the
> advantages of these platforms for the Emacs developers: though some
> advantages exist, they are not that significant, at least IMO, and
> there are disadvantages (described in the GitLab issue).

And yet few of the packages hosted on MELPA — even those that don't get many 
external contributions — are developed using mailing lists (not sure about GNU 
ELPA).  That might suggest that even Emacs veterans see value in these online 
systems (?)

But really, I don't know about this part.  All I was responding to is a comment 
about emailing patches being easier than web forms for newcomers, and about a 
need to fix misconceptions about email.

> IOW, the most important reason for this move is to be more welcoming
> to casual contributors, not to make the job much easier for the
> maintainers.

That's fair (but the maintainers are doing an incredible job today, so it would 
be terrible to make your job harder).  This was also the reason that the Gnome 
and KDE folks cited when they moved to Gitlab (in 2018 and 2020, respectively; 
https://about.gitlab.com/blog/2018/05/31/welcome-gnome-to-gitlab/ and 
https://about.gitlab.com/blog/2020/06/29/welcome-kde/).

FWIW, this was the issue that KDE was using to track requirements for their 
move https://gitlab.com/gitlab-org/gitlab/-/issues/24900 

There isn't much data on whether Gnome moving to gitlab has helped with 
contributions, unfortunately.