Re: purpose and implementation of code reviews

[Alfred M. Szmidt]

   The main implication is that commits from *all* developers should be
   reviewed from now on. Not only of the more junior ones. Not only of those
   developers who frequently make mistakes.

GNU is voulnteer based, such a scheme like this would require paid
individuals.

   Review before or after commit?

     - In critical packages with many developers, such as glibc, it is important
       that patches get reviewed before they get committed. For glibc, such
       tooling is already in place (although the lack of references between the
       bugzilla, the mailing list, and the patchwork site make it tedious to 
deal
       with).

What about other critical packages like Emacs?  There are little to no
code reviews explicitly done AFAIK on parts that are maintained by
others.

     - In packages with few developers, on the other hand, where co-developers
       may not be available for review within 24 hours, requiring review before
       commit would significantly slow down the main developers' workflow. IMO
       for such packages it is appropriate to do the review after the commit.
       (In the 'xz' backdoor case, if there had been a review of *all* commits
       within 4 weeks after commit, it would have been sufficient.)

No, it would not -- e.g., the landlock test intentional failure would
have been missed and WAS missed.

We have packages that are mainly done by a single indivdual, how do
you suggest reviews be done there?  How do you suggest review is done
for packages that are not maintained in VCS?  We cannot mandate that
people use Savannah, VCS -- we can barley ask them to follow the GCS
which is mostly a entierly optional document.