Re: Not usable email content encoding
> "Jonathan" == Jonathan Wakely via Gcc writes: [gerrit] Jonathan> I think it also only very recently gained the ability to group a Jonathan> series of patches together, as it wants a single commit per review. We tried gerrit for gdb for a while, and in the end decided to drop it. The main issue for us is that gerrit's support for patch series is poor. In particular, it doesn't have any way to provide a cover letter (like git send-email --compose), but in gdb we rely on these to provide an introduction to the series -- to help justify the series overall and orient the reviewers. Here's the gerrit bug: https://bugs.chromium.org/p/gerrit/issues/detail?id=924 Based on this I think we all assumed that the situation wouldn't improve. Also, gerrit was pretty bad about threading messages, so it became quite hard to follow progress in email (but following all patches in the web interface is very difficult, a problem shared by all these web UIs). Phabricator, IME, is even worse. Last I used it, it had extremely bad support for patch series, to the extent that Mozilla had to write a tool wrapping Phabricator to make it workable. In gdb we've also considered using an updated patchworks -- with a gerrit-like commit hook it would be possible to automatically close patches when they land, which is patchworks' biggest weakness. (In gdb land we're more concerned with tracking unreviewed patches than with online patch review.) However, this probably would not be a good match for the new From munging, because it would mean extra (forgettable) steps when trying to apply patches from the patchworks repository. TL;DR we're doomed, Tom
Re: Not usable email content encoding
* Tom Tromey: > Also, gerrit was pretty bad about threading messages, so it became quite > hard to follow progress in email (but following all patches in the web > interface is very difficult, a problem shared by all these web UIs). What I found most disappointing was that the web interface doesn't guide you to the next reasonable step for your reviews and patches, like showing comments which need addressing. Tagging messages in an email client for later action actually works better than that, I think.
Re: Not usable email content encoding
On Thu, Mar 19, 2020 at 2:28 PM Florian Weimer wrote: > > * Tom Tromey: > > > Also, gerrit was pretty bad about threading messages, so it became quite > > hard to follow progress in email (but following all patches in the web > > interface is very difficult, a problem shared by all these web UIs). > > What I found most disappointing was that the web interface doesn't > guide you to the next reasonable step for your reviews and patches, > like showing comments which need addressing. Tagging messages in an > email client for later action actually works better than that, I think. I guess if anything we'd want something git-centric now like github or gitlab pull requests & reviews. The only complication is approval then which would still mean manual steps. Patch review would also not be publicly visible and archived(?) so both chiming in late after visible progress and archeology would be harder. I think following all patch reviews by clicking on websites rather than watching gcc-patches is impractical. Richard.
Re: Not usable email content encoding
* Richard Biener: > On Thu, Mar 19, 2020 at 2:28 PM Florian Weimer wrote: >> >> * Tom Tromey: >> >> > Also, gerrit was pretty bad about threading messages, so it became quite >> > hard to follow progress in email (but following all patches in the web >> > interface is very difficult, a problem shared by all these web UIs). >> >> What I found most disappointing was that the web interface doesn't >> guide you to the next reasonable step for your reviews and patches, >> like showing comments which need addressing. Tagging messages in an >> email client for later action actually works better than that, I think. > > I guess if anything we'd want something git-centric now like github > or gitlab pull requests & reviews. The only complication is approval > then which would still mean manual steps. Gitlab has a “merge if CI passes” button, I think. There are similar third-party solutions for Github. > Patch review would also not be publicly visible and archived(?) so > both chiming in late after visible progress and archeology would be > harder. The comments could be archived on a mailing list. But there is only some threading. Maybe this can be compensated to some extent by producing smaller patches, so that there's less reason for mega-review-threads. I don't know if Gitlab supports patch reviews, or if you only can review all the squashed changes in a merge request. Github and Gerrit support comments on individual patches, but Pagure does not, so this is not something that has universal support in all such tools. (I would consider such a feature critical for glibc development.) I haven't figured out yet under what circumstances Github links commits to pull requests in the web UI. I'm not sure if this relationship is available outside the web UI. (Obviously, this is missing from the current gcc-patches feed as well.)
GNU Tools Cauldron 2020 update
Dear all, With the current evolution of the COVID-19 crisis worldwide, we are unfortunately not in a position to maintain the organization of this year’s GNU Tools Cauldron as originally planned in June. We are working on the finalization of postponement options and will let everyone know as soon as everything is confirmed. We apologize for any inconvenience this might cause and ask for your understanding. If you have any concerns or questions, please do not hesitate to reach out to the committee at tools-cauldron-ad...@googlegroups.com. With Kind Regards, Olivier
Re: Not usable email content encoding
On Thu, Mar 19, 2020 at 02:41:05PM +0100, Richard Biener wrote: > I guess if anything we'd want something git-centric now like github > or gitlab pull requests & reviews. The only complication is approval > then which would still mean manual steps. Patch review would also not > be publicly visible and archived(?) so both chiming in late after visible > progress and archeology would be harder. I think following all > patch reviews by clicking on websites rather than watching gcc-patches > is impractical. patchwork used to work great as an archive (it runs for GCC for almost ten years now). It is not meant as a patch review system: instead, it is meant as something for (kernel) maintainers where they can pick up patches to apply (which isn't our workflow: people apply their own patches, in general). It is also useful to find neglected patches, but that only can work if someone (or a group of people) does the work for that. This doesn't work for us. *Used to* work great... With the From: munging, it now has become quite hard (and very annoying) to navigate, and even just to read :-( Segher
Re: Not usable email content encoding
On Thu, Mar 19, 2020 at 02:58:55PM +0100, Florian Weimer wrote: > * Richard Biener: > > I guess if anything we'd want something git-centric now like github > > or gitlab pull requests & reviews. The only complication is approval > > then which would still mean manual steps. > > Gitlab has a “merge if CI passes” button, I think. There are similar > third-party solutions for Github. To actually commit patches is even more trivial than it was with SVN. This is not the hard step. "Merge if CI passes"... Well, it would be nice if we *had* some CI system :-) (But commits should *not* depend on that, and conversely, you should be able to run something on the CI without committing it, as well.) > The comments could be archived on a mailing list. But there is only > some threading. Maybe this can be compensated to some extent by > producing smaller patches, so that there's less reason for > mega-review-threads. We often have discussions on gcc-patches@ (instead of on gcc@). This is mostly natural, and artificially moving that to another ML because some tool is lousy is making new problems, not solving any. Segher
