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

[Jacopo Mondi]

Hello
   just for sake of discussion

On Tue, Jul 30, 2024 at 12:55:10AM GMT, Laurent Pinchart wrote:
> 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.
>

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.

[*] It's more an issue with Linux than libcamera, where I usually only
cc the ML + a few people if the patch is relevant for them.

When I have to review code on gh/gl for non-mainline related projects
I learned to tolerate it by checking out the branch corresponding to
the MR and looking at patches with any tool I like, outside of the web
UI, and simply report comments there. It's a small overhead, but I
think I got to accept it.

Automatic integration with the CI loop is, needless to say, a win.

What still holds me back from jumping on the git**b boat is still

1) I need a (stable) internet connection to be able to do anything. With
emails, once I have downloaded them in my inbox, I can reply off-line
and send them once I got my connection back. This is only relevant
when travelling, and I know there's people that travels more than me
so they might be more affected. I count 3/4 times a year this affects
me, as in most cases I can fetch the branches I need to look in
advance and work on it.

2) vendor lock in. As much as I praise gitlab for being better than
the most direct competitor when it comes to supporting open source and
free software, we're still using a product someone with a legit
business interest is in control of. I would be strongly against using
the instance offered at gitlab.com, now that we're hosted on
freedesktop this is less an issue for me, but still, why gitlab and
not one of the many other alternatives I only heard about and never
really tried out ? emails are certainly the most vendor-neutral medium
I can think of (with caveats, indeed)

> > 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.
>

Not sure I get why the multiple login is an issue if we are only
talking about moving libcamera workflow to the freedesktop gitlab
instance.

Let me add one point, that I try to keep in mind each time this
discussion happens (once a year, at least). I have an email based
workflow I have established during the years. I had to do so (and
enjoyed it, don't get me wrong) for Linux, no ways around it. Now, we
clearly don't have and won't have the same critical mass as Linux and
we know there is people that would have sent patches to libcamera,
maybe small, drive-by changes, if they could have done so using
gitlab. If they have to setup an email based workflow "just for us",
unless they're a bit special or have business reasons to do so, it
won't happen. Now, my question is what is the net gain in having a way
for people to send patches "too" easily, as any patch, even if rubbish
needs reviews and reviews takes most of the core contributors time and
energies.

The elitist in me thinks that if you really care, and if your
contribution is relevant, you will find time (and enjoy) the process
of setting up an email based workflow, and if you don't, we're probably
not missing much from your lost contribution. I understand this is
wrong as a mindset, and even if I'm a bit scared about the quantity of
"thanks but no thanks" contributions we might get, I still think the
we're locking out a lot of brilliant and potentially relevant
contributors by imposing them such an high entrance barrier. I
don't want to alienate people and I think the libcamera project would,
in the long term, be in a better position if easier to access for more
and more contributors, and an email-based development workflow
certainly doesn't help with that.

> > > 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