Re: Code reviews (was: Is it time to drop ChangeLogs?)

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Date: Mon, 07 Mar 2016 22:25:12 -0500
> 
> If we could switch to a system where every patch is reviewed before
> commit, that'd be great.  My own impression is that it will kill the
> development pace because too few people are willing to spend the
> corresponding efforts.

Agreed.  For my part, I can say that I simply don't have enough free
time to review more patches than I do (which is an abysmal little).

> That's why I've followed a practice of giving out write access very
> liberally, with "post-commit spot-check reviews" instead.  Indeed, it
> means that errors in commit messages can't be fixed (we can fix them in
> the ChangeLog files, admittedly, but since I don't use them it doesn't
> help me).

Post-commit reviews also take time.  Do you have an estimation of how
much time per day this takes?

> Maybe we could have a half-way system, where commits are pushed to
> a branch that is "not fast-forward-only", and this branch is then
> auto-merged to the real (fast-forward-only) master branch after a delay
> (one day, maybe?) to give time to fix mess ups before they're cast
> in stone.

A day is nowhere near enough.  IME, a bad commit pushed to master
takes up to a week to be discovered.

More generally, the problem with such a branch is that it won't be
much different from pushing to master, except in rare cases that it
breaks the build, and even that can only be avoided if we set up some
kind of CI system that continuously builds that branch on the main
supported platforms.