Lately whenever I give a presentation, I often at least briefly mention one of my primary motivations for doing what I do: I really like working in global community of people on Free Software.
A concrete artifact of that work is the code landing in git repositories. But I believe it’s not just about landing code – peer review is a fundamental ingredient.
Many projects of course start out as just one person scratching an itch or having fun. And it’s completely fine for many to stay that way. But once a project reaches a certain level of maturity and widespread usage, I think it’s generally best for the original author to “step down” and become a peer. That’s what I’ve now done for the OSTree project.
In other words, landing code in git master for a mature project should require at least one other person to look at it. This may sound obvious, but you’d be surprised…there are some very critical projects that don’t have much the way of peer review.
To call out probably the most egregious example, the bash shell. I’m deliberately linking to their “git log” because it violates all modern standards for git commit messages. Now, I don’t want to overly fault Chet for the years and years he’s put into maintaining the Bash project on his own time. His contribution to Free Software is great and deserves recognition and applause. But I believe that getting code into bash should involve more than just him replying to a mail message and running
git push. Bash isn’t the only example of this in what I would call the “Linux distribution core”.
Another major area where there are gaps are the “language ecosystems like Node.js, Rust’s cargo, Python’s pip etc. Many projects on there are “one person scratching an itch” that other people mostly just consume.
There’s no magical solution to this – but in e.g. the language ecosystem case, if you happen to maintain a library which depends on another one, maybe consider spending a bit of your time looking at open pull requests and jumping in with review?
A vast topic related to this is “who is qualified to review” and “how intensively do I review”, but I think some qualified people are too timid about this – basically it’s much better to have a lightweight but shallow process than none at all.
Now finally, I included “packaging” in the title of this blog, so how does that relate? It’s pretty simple, I also claim that most people doing what is today known as “packaging” should sign up to participate in upstream peer review. Things like build fixes should go upstream rather than being kept downstream. And if upstream doesn’t have peer review, reconsider packaging it – or help ensure peer review happens upstream!