On 23/04/2024 09:56, Mark Wielaard wrote: > Hi, > > On Mon, Apr 22, 2024 at 11:51:00PM -0400, Jason Merrill wrote: >> On Mon, Apr 22, 2024 at 11:24 PM Tom Tromey <t...@tromey.com> wrote: >>> Jason> Someone mentioned earlier that gerrit was previously tried >>> Jason> unsuccessfully. >>> >>> We tried it and gdb and then abandoned it. We tried to integrate it >>> into the traditional gdb development style, having it send email to >>> gdb-patches. I found these somewhat hard to read and in the end we >>> agreed not to use it. >>> >>> I've come around again to thinking we should probably abandon email >>> instead. For me the main benefit is that gerrit has patch tracking, >>> unlike our current system, where losing patches is fairly routine. >> >> Indeed. Though Patchwork is another option for patch tracking, that glibc >> seem to be having success with. > > Patchworks works if you have people that like it and keep on top of > it. For elfutils Aaron and I are probably the only ones that use it, > but if we just go over it once a week it keeps being managable and > nobody else needs to care. That is also why it seems to work for > glibc. If you can carve out an hour a week going over the submitted > patches and delegate them then it is a really useful patch tracking > tool. Obviously that only works if the patch flow isn't overwhelming > to begin with... > > I'll work with Sergio who setup the original gerrit instance to > upgrade it to the latest gerrit version so people try it out. One nice > thing he did was to automate self-service user registration. Although > that is one of the things I don't really like about it. As Tom said it > feels like gerrit is an all or nothing solution that has to be > mandated to be used and requires everybody to have a centralized > login. But if you do want that then how Sergio set it up is pretty > nice. It is just one more thing to monitor for spam accounts... > > Cheers, > > Mark
I've been using patchwork with GCC since, roughly, last year's cauldron. Its main weakness is a poor search function for finding relevant patches, which means that since most patches in the queue aren't being managed it's a bit hit-and-miss finding the relevant patches. Its other problem is that it expects a particular workflow model, particularly not replying to an existing patch discussion with an updated patch (it expects patches to be reposted as an entire series with a new version number, Linux-style). But there are some benefits to using it: I can integrate it with my mail client - it can show me the patch series in patchwork when I receive a mail directly; it integrates well with git with the git-pw module, so I can pull an entire patch series off the list into my worktree from the command line just by knowing the patch series number; and I can manage/track patches in bundles, which is great if I don't have time in any particular day to deal with the email volume. Finally, it's been integrated with our CI systems (thanks Linaro!), so it can automatically pull reviews and run validations on them, then report the results back; often before I've even had time to look at the patch. R.
