Why are we using email patch review instead of GitLab merge requests?

[Kieran Bingham]

Quoting Quentin Schulz (2024-07-31 08:51:21)
> Hi Laurent,
> 
<snip>
> >>> To be honest, I had the very same position as you have: web UI reviews
> >>> are not usable for real work and they get in the way of getting things
> >>> done. I admit I sightly changed my mind recently.
> >>>
> >>> In the last years I've been exposed more to the web forges workflow, and
> >>> even if I still find the review process clunky compared to emails, I
> >>> admit the issue system is proving to be quite helpful for me to
> >>> associate a context to a patch series, and the MR workflow saved me a
> >>> lot of time by providing summarized views of what has changed between
> >>> two revisions of the same series, something I otherwise have to keep
> >>> track of in my work tree, by applying the two revisions and diffing
> >>> them with git. Pushing a branch compared to a ['format patch' + 'copy
> >>> and update the cover letter' + 'check the right people is in cc'[*] +
> >>> 'git send-email'] is certainly faster, I don't think this can be
> >>> disagreed with.
> >>
> >> Just chiming in here: if we had the archives on lore.kernel.org, you
> >> could do:
> >>
> >> b4 diff -v 3 4 --
> >> https://lore.kernel.org/linux-hwmon/
> 20240705213547.1155690-1-linux at roeck-us.net/T//#t
> >
> > I don't think we could get our mailing list archived on lore.kernel.org
> > (or could we ?), but we could setup a public-inbox instance and use
> >
> 
> If I were you I would ask Konstantin. We have archives for U-Boot and
> multiple Yocto MLs (https://lore.kernel.org/?q=yocto and
> https://lore.kernel.org/?q=openembedded) on lore.kernel.org (and it's
> just a mirror of other ML archives I believe, since lists.denx.de,
> lists.openembedded.org and lists.yoctoproject.org are still working just
> fine). I don't know what would make a project's ML match the criteria
> for having archives there, but I think given that libcamera-devel isn't
> that high traffic it shouldn't be much of an issue, no deciding power
> here though :) That would also mean less IT (maybe) for you :)

I've asked for this back in 2022. 'Hosting' the public inbox instance
on kernel.org isn't desired (essentially Konstantin doesn't want the
smtp overhead) - but mirroring it is possible. I assume this is how the
yocto uboot projects work.

So the action is on us (still ... after 2 years) to set up a public
inbox service first.

--
Kieran