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

[Dave Stevenson]

On Tue, 30 Jul 2024 at 17:44, Laurent Pinchart
<laurent.pinchart at ideasonboard.com> wrote:
>
> On Tue, Jul 30, 2024 at 05:36:40PM +0100, Dave Stevenson wrote:
> > On Tue, 30 Jul 2024 at 10:17, Quentin Schulz wrote:
> > > On 7/30/24 9:50 AM, Jacopo Mondi wrote:
> > > > On Tue, Jul 30, 2024 at 12:55:10AM GMT, Laurent Pinchart wrote:
> > > >> 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].
>
> We do something similar for libcamera already. Each commit is checked
> with checkstyle.py and compiled individually, with a single compiler. We
> don't run unit tests on individual commits, and we don't do full
> compilation with all the compiler versions, as that would be too costly
> in terms of CPU usage for the gain. As usual with CI, there's a balance
> between costs and benefits.

Presumably not on Github seeing as none of libcamera is hosted there.

I was responding to the dismissal of Github as a platform due to the
CI workflows not being able to support bisectability. That is not the
case.

> > [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 :) ).
>
> --
> Regards,
>
> Laurent Pinchart