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

[Quentin Schulz]

Hi Jacopo,

On 7/30/24 9:50 AM, Jacopo Mondi wrote:
> 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.
> 

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@roeck-us.net/T//#t

As for my opinion as a non-contributor to libcamera on contribution 
workflow, I wrote this piece[1] almost three years ago when we started 
to receive an influx of requests from not-yet (IIRC) contributors to 
migrate to GitLab/GitHub for Yocto/OE. While I now regret the tone in 
some parts of the mail, I still agree with the content of it.

For me, GitLab and GitHub are just not the tools for when one cares 
about the ability to bisect as the CI is run on the top commit. Maybe 
libcamera doesn't care about it (I don't know, and not a judgment here; 
also, mesa seems to be doing fine with this workflow for example?).

I'm also a bit curious about sourcehut which has ML contribution, 
integrated CI and all. I have never tried it though.

FYI, 
https://www.reuters.com/markets/deals/google-backed-software-developer-gitlab-explores-sale-sources-say-2024-07-17/. 
Not sure how things will evolve with GitLab once they're bought.

[1] https://lists.openembedded.org/g/bitbake-devel/message/12995

> [*] 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.
> 

FYI, https://b4.docs.kernel.org/en/latest/contributor/send.html
b4 send allows to send series through a web submission endpoint. I have 
not tested this personally nor do I know people who have done so, but 
this seems to be a way to contribute without hopefully too much to 
figure out except following the instructions.

The fact is, the longer the project waits to migrate to another 
workflow, the less likely it will because more tooling will be 
integrated with the current workflow, essentially locking in itself. I 
think the question to ask project leadership is:
- would biggest contributors and maintainers to the project still 
contribute/maintain if it were to change contribution workflow?
- can the project afford a time during which development stalls a bit 
(or maybe more than a bit) so the workflow can be changed?

For OE/Yocto, the answers were pretty simple: mostly no. But maybe 
libcamera is in a different situation (not being a 20yo project being 
one :) ).

Cheers,
Quentin