Our project inherited a patchbomb-based workflow from Linux. Many of the individual members have also contributed to gitlab/hub based projects, and appreciated a lot of the automation available, as well as recognizing the lower barrier-to-entry of not having to figure out how to get an SMTP connection. So a few years ago we experimented with allowing "small" patches to be sent via PR on gitlab, and doing the review there.
Basically, everyone agreed that actually doing the review on gitlab was a lot worse compared to email. There's just so much more flexibility.
It's not off the table that we may give it a try again, because the advantages of having concrete pull requests (and issues and...) rather than patch series is pretty significant. But if you're familiar with doing email-based review, I think it's still a far superior; and you're definitely giving something up when you move away from it.
>Basically, everyone agreed that actually doing the review on gitlab was a lot worse compared to email. There's just so much more flexibility.
Could you elaborate? This is truly shocking to me. Admittedly I have never worked on a project with an email-based workflow, but I can't think of how email would allow comments inline with the patch, which is an incredibly beneficial feature to me.
I like git patches...I can scan through them, write comments, and maybe strip out files that aren't necessary (if you have two isolated networks and are syncing code in between). I'm a fan of some of these ambitious git projects like GitLab but there's just something about syncing git through patches (like email).
Well yeah, replying in-line to the patch to make comments is definitely a requirement. :-)
You always reply with quotes; and you always reply inline, below the thing you're replying to. Quoted material is typically indicated by '>'.
So for one thing, you can easily trim your reply to just the bits of the patch that you think is important; that makes it easy for anyone reading; you don't have to skip over large parts of the thread.
Then you can also re-arrange what you're replying to, to make it make your reply make more sense.
Furthermore, suppose A replies to the patch and makes comments 1, 2, and 3 (inline in a single email). When person B replies to A's email, they typically also send a single email, perhaps with replies 1' and 3' (trimming out comment 2, which they don't care about). This means if you've read A's mail, you can just read B's mail, and all the "new" comments are collected in one place (with the thing they're replying to).
Contrast the above with gitlab, where A's replies 1, 2, and 3 are spread throughout the patch; and B's replies will also be spread out, meaning you have a kind of discoverability problem to see both 1' and 3'.
And suppose in the course of talking about something you realize this bug may actually be a security issue -- you can remove the list, cc' "security@", and pick up the discussion without having to do any copy & paste. Same goes if you want to make a private comment, or bring something to someone's attention; just reply, remove everyone else, and say "FYI".
I wish I had a really good recent example to show you, but a quick skim of today's threads isn't anything special. :-)
I mean, I was arguing with people online [1] on BBS's in the early 90's, and I was on Usenet back when that was the main social network; so this "reply and comment inline" way of having a discussion is pretty well ingrained for me. But there are people on my team in their early 30's who also took to the email workflow really quickly too.
Thanks for taking the time to respond. I'm surprised to find that there are people out there who think endlessly nested >'s are a good solution, but it's always nice to have one's world view expanded :)
For one thing, most GUI mail readers will automatically convert the `>` into nested block quotes.
For another, it's not common to see more than 2 levels of `>` (your text, the thing you're replying to, and the thing they're replying to); and yes, when it gets past 4 it begins to get really unreadable, so my gut feel is that it's extremely rare (although I wouldn't be certain without doing some sort of data mining).
As I said, the main advantage of using email is the flexibility you have in editing the response; part of learning how to use the review workflow effectively is learning how to present the context; which means trimming the replies to balance information and readability.
Basically, everyone agreed that actually doing the review on gitlab was a lot worse compared to email. There's just so much more flexibility.
It's not off the table that we may give it a try again, because the advantages of having concrete pull requests (and issues and...) rather than patch series is pretty significant. But if you're familiar with doing email-based review, I think it's still a far superior; and you're definitely giving something up when you move away from it.