|
From: Mark W. <ma...@kl...> - 2023-03-23 09:15:18
|
Hi Nick, On Thu, Mar 23, 2023 at 10:08:51AM +1100, Nicholas Nethercote wrote: > All the Rust projects I work on use GitHub, and in terms of usability and > productivity it's miles ahead of how Valgrind development works. I think github is unacceptable for Free Software projects, which I believe should use free software tools and not a corporate controlled proprietary platform: https://mako.cc/writing/hill-free_tools.html https://giveupgithub.com/ But that doesn't mean I don't agree with you. There are some really nice concepts in these "code forges". And there are free software implementations like https://codeberg.org/ https://docs.pagure.org/pagure/ https://sourcehut.org/ and (self managed) gitlab ce. valgrind already has an official mirror on sourcehut (like all other sourceware projects): https://sr.ht/~sourceware/valgrind/ > If I were king of the world here's how I would drag Valgrind's development > practices forward by 10-20 years. > > - Move the repository to GitHub. Require all changes to be done via pull > requests, with no direct pushing. > - Set up some CI testing via GitHub Actions. Require that all pull > requests pass these tests before merging. > - Lots of projects require a review approval before a pull request can > be merged. But that might be too hard for Valgrind to start with, given the > small number of active contributors. Modulo using github these sound like interesting ideas. Forcing this workflow might be a bit heavy weight. But we could use sourceware try-branches so all commits go through the CI builders. Requiring all passing builds will be a bit of a puzzle since out testsuite(s) aren't zero-fail. > - Switch from KDE bugzilla to GitHub issues for bug reporting. Not sure > what I'd do with existing open bug reports, whether it would be worth > importing them to GitHub issues somehow or not. I would consider moving to sourceware bugzilla, which would make it easier to connect commits/patches with issues. The downside is that all bugs get renumbered. What benefit do you see from GitHub issues over bugzilla? > - Use auto-formatting tools, such as clang-format. (Possibly even moving > from 3 space indents in C code to 2 or 4!) Sourceware builder could help with that, we can setup a CI bot that runs such a formatter over all commits to check formatting. I have seen that work very nicely with the python black formatter. But for C code/clang-format it seems the formatter seems not that good/stable. > - Change the docs from that XML-based thing we use (groan) to something > nicer, probably involving Markdown. Not against, but a lot of work. And with the make check xml linter checks writing new docs has become a lot nicer. We should however setup a buildbot to always create the docs on each commit. > - Website: not sure... a lot of it could be naturally hosted on the main > GitHub page. It might be nice to still have valgrind.org, though, but > perhaps greatly stripped back. What would you propose? The website is in git now, but uses php for a few things. https://sourceware.org/cgit/valgrind-htdocs we could drop the php and replace it with a more simpler markdown based site? Cheers, Mark |