diff options
Diffstat (limited to 'reviews/mailing-lists.md')
| -rw-r--r-- | reviews/mailing-lists.md | 67 |
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/ |