Re: Updated Sourceware infrastructure plans
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 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
Re: Updated Sourceware infrastructure plans
On 23/04/2024 04:24, Tom Tromey 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. > > Jason> I think this is a common pattern in GCC at least: someone has an > Jason> idea for a workflow improvement, and gets it working, but it > Jason> isn't widely adopted. > > It essentially has to be mandated, IMO. > > For GCC this seems somewhat harder since the community is larger, so > there's more people to convince. > > Tom I've been forced to use gerrit occasionally. I hate it. No, I LOATHE it. The UI is anything but intuitive with features hidden behind unobvious selections. IMO It's not a tool for a casual developer, which makes it a bad introduction to developing software. R.
Re: Updated Sourceware infrastructure plans
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 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.
Re: Updated Sourceware infrastructure plans
* Jason Merrill: > On Mon, Apr 22, 2024 at 11:42 AM Tom Tromey wrote: > > > "Frank" == Frank Ch Eigler 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
Re: Updated Sourceware infrastructure plans
On Tue, Apr 23, 2024 at 2:32 AM Richard Earnshaw (lists) via Gcc wrote: > > I've been forced to use gerrit occasionally. I hate it. No, I LOATHE it. > The UI is anything but intuitive with features hidden behind unobvious > selections. IMO It's not a tool for a casual developer, which makes it a bad > introduction to developing software. I would be shocked if GCC ever adopted Gerrit. But I don't understand this objection. Yes, Gerrit is not a tool for a casual developer. But so what? Casual developers don't have to use it, except that they have to run a particular git command to submit a patch. It's the GCC maintainers who have to use Gerrit. Ian
Re: Updated Sourceware infrastructure plans
> Indeed. Though Patchwork is another option for patch tracking, that > glibc seem to be having success with. We tried this in gdb as well. It was completely unworkable -- you have to manually clear out the patch queue, meaning it's normally full of patches that already landed. I know glibc has success with it, but I wouldn't consider it for gdb unless it gained some new abilities. Tom
Re: Updated Sourceware infrastructure plans
On 2024-04-23 11:08, Tom Tromey wrote: >> Indeed. Though Patchwork is another option for patch tracking, that >> glibc seem to be having success with. > > We tried this in gdb as well. It was completely unworkable -- you have > to manually clear out the patch queue, meaning it's normally full of > patches that already landed. I know glibc has success with it, but I > wouldn't consider it for gdb unless it gained some new abilities. The thing that Gerrit excels at is tracking the different versions of a given patch, being able to easily diff versions, etc. And then mark a patch as merged once it's committed to master. Patchwork doesn't have this capability built-in (AFAIK). You can try to do some automation, but I doubt that any system based solely on getting patches from a mailing list can ever be as good as something like Gerrit for this. Simon
