Re: Gitlab Migration

[Eli Zaretskii <eliz@gnu.org>]

> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Thu, 26 Aug 2021 14:36:17 -0400
> 
> - It requires less expertise with git and the patching workflow.  Committing to "one branch per patch" means that contributors don't need to know how to prepare and send or apply patches.  It also means that maintainers (or bots!) can push fixes directly, instead of requesting them.  For example recently I opened a pull request for a Python project I had never contributed to, and an automated system promptly pushed an additional commit to the branch to reformat my code using the project's preferred style.  With Emacs patches we typically ask the author to fix issues that are spotted by hand by a reviewer. 

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.

> - 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.

And it isn't like GitLab and similar platforms don't have similar
issues: e.g., I don't know to this day how to reply to a specific
comment there (as opposed to the last one), nor how to cite portions
of the comment to which I respond.  And that's _after_ I overcome the
shock of not being able to use sophisticated editing commands and
spell-checking.

> 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.  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).

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.