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

[Laurent Pinchart]

Hi Nicolas,

On Mon, Jul 29, 2024 at 05:31:59PM -0400, Nicolas Dufresne wrote:
> Le dimanche 28 juillet 2024 à 18:54 +0300, Laurent Pinchart a écrit :
> > On Sun, Jul 28, 2024 at 03:17:18PM +0000, Barnabás Pőcze wrote:
> > > 2024. július 28., vasárnap 17:07 keltezéssel, Neal Gompa írta:
> > > 
> > > > Hey folks,
> > > > 
> > > > I just found out today that libcamera exists on FDO GitLab[1], so I'm
> > > > wondering why we aren't just using merge requests over there instead?
> > > > Among other things, it makes it much easier for people to track what's
> > > > going on with proposed changes, simplifies the process for new
> > > > contributors, enables immediate feedback on the viability of
> > > > contributions, and allows the mailing list discussions to be more
> > > > focused on higher level things.
> > > > 
> > > > [1]: https://gitlab.freedesktop.org/camera/libcamera
> > > 
> > > I have already asked about this. As far as I recall the TLDR is that the people
> > > in charge like the mailing list + patchwork + bugzilla + etc. workflow better,
> > > and GitLab is only used for CI.
> > 
> > The main issue with gitlab is the awful patch review and discussion UI,
> > couple with the fact that it's quite difficult to customize workflows
> > given the limited number of available tools compared to mailing list
> > workflows.
> 
> Your answer seems completely based on personal taste (I'm fine with opinions,
> don't read me wrong). Perhaps it could be nice to rephrase to make it clear its
> a choice rather then bashing other flows. 'Awful' is your personal opinion (also
> impression if you have never submitted MR to other projects). As an example, I
> tend to describe the email flow the exact same way (or just 'painful'), but I'm
> very cautious when saying that out-loud on ML, since this is clearly a personal
> taste and I don't pretend others must agree.

There's certainly some amount of personal taste of course, as well as
habit. These taste and habit are shared to various extents by several of
the libcamera main contributors, but there's probably a bias given that
they also come from a kernel development background. I will let them
speak for themselves if they wish to do so.

> For me, MR let me silently start watching a specific changes, and notify me only
> for what I've explicitly asked for. With the current email, I'd have to send an
> email to everyone asking to "CC me please", or having to watch for all the
> unrelated notifications. On Linux there is tools to change this, with filters
> and stuff, but its specific to Linux mailing list server, and not as easy and
> intuitive.

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.

> If you are working on more then a single project (like a dozen) this
> is a big deal. As a side effect, it can takes several days for me to find the
> time to parse through the list and give a simple Ack.
> 
> Gitlab specifically clearly lack a feature to comment against the commit
> message, and this I'll keep pushing to gitlab project, but that imho is not
> enough for me to consider it 'Awful'. I've got used to copy the messages as a
> comment, and then review it inline, its a small overhead.

That's one of the missing features, yes. Another big issue that I
mentioned is the difficulty to customize workflows. I will also call
editing review comments and code in the git..b web UI "awful"
unapologetically.

You mentioned working on more than a single project, I actually find the
mailing list workflow much better in that case. I get everything in a
single e-mail client, I don't have to log in github.com, gitlab.com,
gitlab.freedesktop.org and all the other ones independently. Until we
get some federation protocol for forges with decent clients that don't
run in web browsers, I'll have a hard time changing my mind.

> > Merge requests themselves are fine I think. I have it somewhere on a
> > TODO list to experiment with bridging them to e-mail. That would be a
> > one-way bridge though, a merge request would be translated to a set of
> > patches sent to the mailing list, and reviewed there. I'm not sure when
> > I could find time to work on this.
> 
> At least this would trigger CI before we even code review, which as a in-
> frequent contributor I appreciate, cause with low practice I tend to do more
> mistakes. As CI gets bigger, it also gets more difficult to run everything
> locally.

That we agree on, and that's aligned with our plan, we will continue
ramping up the usage of CI.

-- 
Regards,

Laurent Pinchart