Re: [RFE] Migration to gitlab

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 17 Mar 2019 05:17:50 +0300
> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
> It's a lot of contributors out there; at the same time, I see very
> little patches on emacs-devel list.

Patches should not be sent to emacs-devel at all, they should be sent
to the debbugs tracker.  And I looked at the bug list for the past 2
weeks, and counted around 25 patches there, i.e. an average of 1.5
patch per day -- not a small amount by any measure.

> A lot of open-source projects already migrated to gitlab: all 
> FreeDesktop projects, all Gnome projects; and KDE are likely to migrate 
> soon too².

I can show you several projects that didn't.  Each project decides on
their own, as it should be.

> Gnome reports: "After switching to GitLab, I noticed almost
> immediately an increase in contributions from people I hadn’t met
> before. I think GitLab really lowered the threshold for people
> getting started"³.

I don't know enough about these projects to tell whether their
experience is significant enough for us.  Some metrics are missing:
how many SLOCs are in each project? how many distinct areas of domain
expertise are needed to cover the entire codebase? how many developers
who review patches? which language(s) is each project written in?
etc. etc.

In general, Emacs is unlike any other Free Software project by many of
these metrics, so techniques and procedures that work elsewhere
don't necessarily fit what happens here.  We must assess the
techniques, procedures, and the respective tools in the context of the
problems we need to solve and the resources we have to solve them.
Blindly copying experience by others is not a good idea.

> here's a rarely mentioned point, why in particular mailing-list
> workflow is hard for newcomers: almost every mail client out there
> breaks formatting by default; and configuring that out isn't always
> easy

This is Emacs you are talking about, and Emacs developers you are
addressing.  Most of us use some Emacs-based MUA, where such
atrocities just don't happen.

> 	2. Gitlab makes addressing review comments easier. With mailing lists 
> workflow you either need to α) send a v2 of the patch; which is a 
> little frustrating: you need to find message-id to feed it to 
> git-send-email, and then you need to make sure its title lines up with 
> the rest of the series. Or β) resend whole patch-series; which can be 
> just redundant when all you did was a one-line change, and clutters the 
> mailing list. Also, upon sending v3, v4, etc. you need to save 
> somewhere changes since v1. You can put it in actual commits, but for 
> git-history this information is unnecessary.

You seem to be talking about something that happens in other projects.
There are no requirements in Emacs development to do any of that
stuff: you don't need to give versions to your patches, you don't need
to make sure the titles match, etc.  We don't even require you to use
"git format-patch", although it is certainly appreciated.  You _can_
do all of that if you want, but no one requires you to.  Quite a few
people sent just output of the 'diff' command, and no one rejected
that just because it didn't include all the bells and whistles.

So I see no reason for contributors to do anything beyond starting a
local branch and delivering the patches from there.  I'm sure sending
patches relative to the master branch is very simple, even with Git.
And if even that is too complicated, simply rebase on the latest
master and send the diffs.  How hard can that be?

> With gitlab workflow, on the other hand, you just force-push changes
> to the branch that has merge-request opened. A single command, that
> it.

Likewise to send a patch from a local-branch commit: a single command,
issued from your Emacs MUA via "C-u M-!".

> 	3. CI. I've recently seen someone on emacs-devel⁵ asking a 
> contributor to run their syntax-checking script on a regular basis. 
> That's becase you can't run any check on a code hanging out there on a 
> mailing list in pure air. Gitlab supports CI, i.e. one can set it up to 
> run unit-tests for every merge-request created, so these errors get 
> caught before getting to the tree; and possibly even before getting to 
> eyes of reveiwers.

We already have a server that runs several types of build on each
commit, courtesy of Glenn.  If you stick around long enough, you will
see Glenn blaming commits that broke some build.  This is not exactly
CI, and it runs only on something that lands on master, but it does
mean we are not exactly in the caves here, even without Gitlab...

> 	4. Impossible to lose "merge request". I've seen in Emacs docs an 
> advice to send patch series to a bugtracker, because on emacs-devel 
> they can easily be forgotten. That can't happen so easily with gitlab, 
> where you have a tab with open merge requests.

Can't happen on the tracker, either.  Yes, patches should be sent
there, not here.

> 	5. Discussion on patch series is easier to read. On mailing lists can 
> quickly appear a dozen of no longer relevant review mails, that refer 
> to something that was addressed. In Gitlab the addressed comments can 
> be marked as such, and get collapsed.

I can assure you I am able to filter my email messages as efficiently
as collapsing on Gitlab, if not more so.  I really hope a new system
that we will some day start using will give us more than just an
ability to filter out irrelevant responses.

> 	6. More tightly integrated bugtracker. When a commit refers to an 
> issue, it can be seen from inside the issue. This is useful e.g. when 
> someone fixed a problem, but for some reason couldn't address review 
> comments, leaving the code behind. Then later peoples who stumble upon 
> the same issue can just improve the code instead of doing research and 
> writing it on their own.

You can view each bug/issue via an Emacs package (debbugs, it's on
ELPA), or via a Web browser.  In this way, you also see all the
patches, and can pick up where others left off.

> 	7. Unclear how to download a patch-series from mailing list.

Again, try the debbugs package or point your Web browser to debbugs.
Patches are all there.

That said, I'm not saying we should not consider changing our
processes and tools.  We just need to do that while being aware of the
job(s) to be done by patch reviewers and the resources they have.  For
starters, how many people do you think review patches for Emacs?  It's
good to know the answer before we discuss measures for increasing the
patch flow...

Thanks.