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

[Dave Stevenson]

Hi

On Tue, 30 Jul 2024 at 10:17, Quentin Schulz <quentin.schulz at cherry.de> wrote:
>
> 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?).

Minor interjection that it is possible to run CI workflows against all
the commits in a PR on Github.
We're not currently doing it for building the kernel (although I would
like to add this), but we are using the webispy/checkpatch-action at v9
[1] workflow to run checkpatch against all commits in every PR [2].

  Dave

[1] https://github.com/webispy/checkpatch-action
[2] https://github.com/raspberrypi/linux/blob/rpi-6.6.y/.github/workflows/checkpatch.yml

> 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