commit 6016afc424625addff93094ef57c63f4eeebbb17
parent aa6477e5e862fb34201daf9e084583bd56449ace
Author: Kévin Le Gouguec <kevin.legouguec@gmail.com>
Date: Thu, 29 Aug 2019 23:11:47 +0200
Comment on an old emacs-devel thread about migrating to GitLab
This one has been on my TODO list for a while.
Diffstat:
2 files changed, 68 insertions(+), 1 deletion(-)
diff --git a/README.md b/README.md
@@ -1,5 +1,5 @@
# Peniblec's Memory Leaks
-## still reachable: 9124 words in 22 pages
+## still reachable: 9552 words in 22 pages
Hi! I am a software engineer interested in [a bunch of things].
diff --git 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/
