5 ms·
Everyone I know who has had to use Gerrit has absolutely, utterly despised it. Until I got a job working as a kernel developer I had never had to use emailed p
by ajdlinux 10y ago
Everyone I know who has had to use Gerrit has absolutely, utterly despised it.
Until I got a job working as a kernel developer I had never had to use emailed patches. It simply isn't an "absolutely necessary" skill for a good developer these days.
The kernel community is too attached to email patch submission for it to ever move away, and to be fair, email does have the benefit of being scalable and matches our decentralised workflow much better than any of the current alternatives.
But it's still not good. There are plenty of ways to screw up email threading or forget conventions on labelling patchset versions or whatever (this happens all the time). You have to rely on external tools such as Patchwork to provide a bare minimum of state-tracking. There's not much by way of generic CI tooling that's designed with email in mind (I'm working on this!). Doing code review from an email client definitely has its benefits, but it's also limiting - web-based code review tools have much more scope for experimenting with better ways of presenting comments.
I can't see the Linux kernel ever moving away from email, and honestly it's not too bad once you've figured out your workflow, but I would like to see kernel hackers thinking about what it is that the kernel community loves so much about email compared to GitHub and other centralised services. It is disappointing to see other large open source projects becoming incredibly dependent on a for-profit proprietary software company that may well not survive the next few years. How can we do proper decentralised version control and development better?
- deleted 10y ago[deleted]
- rando832 10y agoI used gerrit and did not utterly despised it. Hi.
- hueving 10y ago>Everyone I know who has had to use Gerrit has absolutely, utterly despised it. Everyone I know who has had to use github has utterly despised it. I work with a lot of systems and kernel programmers that use gerrit or email workflows. See how anecdotes aren't very useful?
- ajdlinux 10y agoIt should probably be clarified that the people I know who despise Gerrit actually prefer email workflows. They're all kernel programmers.
- lucb1e 10y agoNo because pretty much everyone will know counterexamples of the later anecdote but not the former. I'm all for facts and statistics instead of personal experiences, but I doubt HN would survive the night if we suddenly prohibited personal experiences and required a double blind test with a good sample size before posting a single comment.
- hueving 10y ago>No because pretty much everyone will know counterexamples of the later anecdote but not the former. Just because so many more people use Github. It's easy to shit on less popular things via second-hand anecdotes like you did because there is a good chance very few users will see it. Consider something like this: "Everyone I know who had to use the flight control computer of the F-35 has absolutely, utterly despised it." So few people will be able to refute that in this forum that many people would just take what you said at face value and assume the F-35 flight control computer is garbage. "People tell me X" is just a terrible form of discussion because you can't speak authoritatively on what they said X if you are pressed for details. It's just noise without any depth. >I'm all for facts and statistics instead of personal experiences What you provided wasn't even as good as a personal experience. It was a personal experience of a conversation you had with someone else about their personal experience.
- ymse 10y ago> There's not much by way of generic CI tooling that's designed with email in mind (I'm working on this!). I am interested in learning more about this. Can you share some details? Is there a prototype?
- djeikyb 10y agoi absolutely loved it, especially compared to atlassian's bitbucket code review features.
- webmaven 10y ago> There's not much by way of generic CI tooling that's designed with email in mind (I'm working on this!). Ooh, interesting. Where can I find out more? BTW, you might consider supporting NNTP as well, among other advantages, crappy email clients can't screw up the threading & you avoid Reply-To munging debates.
- durin42 10y agoAll the communities I know that are centered around diff-in-email patch review are quite frustrated by the available GUI tools (most of them are only good for one patch at a time, or treat an entire stack of patches as one change). If you get somewhere with this, let me know? We might be interested in testing it on Mercurial depending on how it integrates with the email side...
- mugsie 10y agoSure, gerrit has a learning curve. When you end up using it for a long time, going back to pull requests is awful. Its basic things: - history of a PR - I cannot see the diff of last version of the patch and latest - dependant changes - I need to do some work that depends on a patch someone else is working on. This can't be done in github. - clean history - no "added tests", "fixed docs typo" etc commits I learnt recently that most people don't use git-review[0] - and yeah, if you are manually doing the "git push gerrit ref/for/master" crap, it's really annoying. but git review and repo were written to help that. 0 - http://docs.openstack.org/infra/git-review/ http://docs.openstack.org/infra/git-review/
- breakingcups 10y agoI've only used Gerrit occasionally, but when I had to the experience was mostly pleasant. Getting set up is a bit more work than just git push but it made sense after reading into it. Maybe it's a matter of configuration?