Comment on an old emacs-devel thread about migrating to GitLab

This one has been on my TODO list for a while.

1 files changed, 67 insertions, 0 deletions

diff --git a/reviews/mailing-lists.md b/reviews/mailing-lists.md
index c63d376..0d7456d 100644
--- a/reviews/mailing-lists.md
+++ b/reviews/mailing-lists.md
@@ -66,3 +66,70 @@ case.
 
 [completion-documentation]: https://lists.gnu.org/archive/html/emacs-devel/2019-01/msg00504.html
 [icomplete-issue]: https://gitlab.com/peniblec/memory-leaks/commit/dcc0c05dc1f6a22645bf9355b72aa44b49776620
+
+## 2019-05
+
+### [\[RFE\] Migration to gitlab][migration-gitlab]
+
+Eli Zaretskii's comprehensive answer to the question: "How could
+moving to a GitLab-centric workflow possibly make a maintainer's life
+worse?"
+
+My interpretation:
+
+Emacs's development infrastructure is pretty threadbare by modern
+standards.  Contributions, drive-by or otherwise, linger as
+unremarkable Debbugs attachments until someone takes the time to try
+the patches out.  Once the discussion branches into multiple
+sub-threads, it can be hard to track the "current state" of the patch
+series.
+
+A Continuous Integration server [exists][emacs-ci], but it only tracks
+branches on Savannah AFAIK; regressions can only be identified if
+someone takes the time to run tests locally (at best) or once the
+patches have been committed to the Emacs repository (at worst).
+Contrast with GitLab-centric projects where anyone "driving-by" is
+automatically greeted with a test suite report.
+
+We are reliant on the unyielding dedication of extremely competent
+maintainers to review contributions, condemned to spend CPU cycles
+checking for breakage and waste heartbeats pointing out trivial
+formatting issues, before they can move on to higher-level review
+(e.g. feature design, documentation clarity).  The push for "better
+tooling" is motivated by the prospect of lowering the bar for
+participating in maintenance.
+
+Yet despite the dismal state of the current server-side tooling,
+GitLab *as a maintainer frontend* lacks many features that some Emacs
+veterans expect.  Some of the facilities Eli lists may eventually get
+equivalents in GitLab's web UI, but neither the GitLab UI nor the
+browser it runs on will ever provide a completely reprogrammable
+environment one can enhance on-the-fly.
+
+To borrow terms from [Josh Triplett's comparison of Rust vs. C for
+systems programming][compelling-vs-parity], the GitLab server offers
+*compelling features* over Debbugs, but the GitLab web UI does not
+provide *feature parity* with Emacs.
+
+AFAICT, some paths of least resistance for better development tooling
+would be
+
+- extending Debbugs to push a patch series as a branch on EMBA, and
+  report the test results,
+- adding scripts to check commit messages against the expected
+  Changelog format, and suggesting templates based on the diffs
+  (i.e. what `diff-add-change-log-entries-other-window` does).
+
+Full interoperability between maintainers who would like a web UI for
+reviews, and maintainers who prefer the versatility of simply quoting
+patches in a mail-composition buffer sounds tricky.  The CI server
+would need to break quoted-patch emails down into { quoted hunk,
+comment } pairs so that the comments show up correctly (i.e. properly
+cross-referenced to the hunk being discussed) on the web UI; not sure
+if some platform already supports that; maybe [sourcehut][srht] took a
+stab at it?
+
+[migration-gitlab]: https://lists.gnu.org/archive/html/emacs-devel/2019-05/msg00306.html
+[emacs-ci]: https://emba.gnu.org/emacs/emacs/pipelines
+[compelling-vs-parity]: https://hub.packtpub.com/rust-is-the-future-of-systems-programming-c-is-the-new-assembly-intel-principal-engineer-josh-triplett/
+[srht]: https://sourcehut.org/