* Jason Merrill: > On Mon, Apr 22, 2024 at 11:42 AM Tom Tromey <t...@tromey.com> wrote: > > >>>>> "Frank" == Frank Ch Eigler <f...@redhat.com> writes: > > >> [...] I suggest that a basic principle for such a system is that it > >> should be *easy* to obtain and maintain a local copy of the history > >> of all pull requests. That includes all versions of a pull request, > >> if it gets rebased, and all versions of comments, if the system > >> allows editing comments. A system that uses git as the source of > >> truth for all the pull request data and has refs [...] > > Frank> Do you know of a system with these characteristics? > > Based on: > > https://gerrit-review.googlesource.com/Documentation/dev-design.html#_notedb > > ... it sounds like this is what gerrit does. > > Someone mentioned earlier that gerrit was previously tried > unsuccessfully. I think this is a common pattern in GCC at least: > someone has an idea for a workflow improvement, and gets it working, > but it isn't widely adopted.
We used it for glibc briefly. It failed in part because we were too kind and didn't give negative feedback in the tool itself (making it less useful for contributors), and because it was deployed on the side alongside the usual mailing list patch submission process. It may be worth a try again, but this time with brutally honest feedback (-2 and whatnot). On the other hand, Gerrit appears to require Bazel to build, and as far as I understand it, setting up and maintaining a Bazel build environment that meets our requirements (basically: no mystery binaries) is a very big task. Thanks, Florian