One minor thing to consider is that some comitters are more familiar
with certain parts of the library than others. As an example, I am most
familiar with the exec utility and the nightly build infrastructure.
These sorts of familiarity are generally known to the other active
comitters. If I am making changes to a part someone else knows better
than I, I will generally ask them to review it, even if the change might
be considered minor. However, if the change alters a section I am very
familiar with, I am more likely to commit the change without asking for
a review of it.
Unfortunately, it's hard to codify this knowledge in a concise manner,
and explicitly designating ownership of every file would almost be an
exercise in futility.
--Andrew Black
Martin Sebor wrote:
William A. Rowe, Jr. wrote:
[...]
So I would like to propose that we all follow a relaxed form of
the Review-Then-Commit policy, where "simple" or "obviously safe"
changes be allowed to go in under the Commit-Then-Review process.
I don't think it's necessary to precisely define what "simple"
or "obviously safe" means. It's a judgment call.
I might suggest the reverse, where the tree operates under C-T-R,
with R-T-C strongly requested for all larger patches, patches which
would exhibit more complex behaviors under multiple compilers, and
certainly build system changes.
Yes, that probably makes more sense given that most of our changes
have been of this nature (small isolated patches). Thanks for the
suggestion, I'll offer it as one of the two options to vote on and
let the majority decide between the two variations on the same
theme:
1. CTR default with big/risky patches to follow RTC.
2. RTC default with simple patches to follow CTR.
Unless there's more discussion I'll get the vote going tomorrow.
Martin
