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

[Kieran Bingham]

Quoting Nicolas Dufresne (2024-07-31 19:41:02)
> 
> Le mardi 30 juillet 2024 à 10:11 +0200, Milan Zamazal a écrit :
> > Laurent Pinchart <laurent.pinchart at ideasonboard.com> writes:
> > 
> > > For what it's worth, we would like to setup a public-inbox instance for
> > > libcamera, to enable usage of tools such as b4 and lei.
> > 
> > One thing I miss here is to know whether a patch (or series) is merged
> > or not.  I can obviously search in the repo but a notification attached
> > to the review thread or something similar would better fit the workflow.
> > Any idea?
> 
> This is obviously supposed to happen, your reviewer should go back and say that
> this has been merged (literally every time), but the email workflow depends on

'obviously supposed to happen' ... but I intentionally don't because
it's extra mails (noise?) on the list.

I can start doing so if it's preferred, or maybe we can hook in
patchwork to start mailing the list?

Though yes - I absolutely dislike that I have also on occasion reviewed
patches that are already merged.

> human consistency. I notice this issue in Linux Media submsystem too. The
> patchwork utility is probably meant to fix that, but a bit like bugzilla, this
> tool seems slightly stuck in the past. It also (from an external obvserver)
> tends to be out-of-sync with and require human intervention to say up-to-date.

Patchwork helps a little on this - as I get tags from patchwork in my
mail client showing the state - but of course it's not foolproof as
patchwork doesn't always get updated. Indeed there's definitely manual
processing required to keep patchwork up to date.

--
Kieran