Martin Sebor wrote:
>
> The policy we have in place ("Review-Then-Commit except as noted")
> is intended to prevent regressions on rare platforms that most
> committers don't have access to and are unable to test their changes
> on by giving those of us who do have access to and an extensive
> experience with such platforms the opportunity to review and give
> feedback on such changes. I think it still is a reasonable policy
> in general but I also think that, when applied rigidly, it could
> get in the way of productivity.
Although the goal is noble, committers themselves weren't a good
metric of this. Rather, guidelines of specific platforms or edge
cases would have been more reflective of the desire.
> Small changes, or changes that
> are obviously safe, can be committed immediately without requiring
> people to go through the review-then-commit process. At the same
> time, big changes should probably be reviewed before committed,
> regardless of who makes them and what platforms they have access
> to.
Agreed - how to define, of course.
> 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.
> Does this sound reasonable to everyone? Are we ready to have
> a vote on this proposal?
Either way, I'd be +1 on your proposal.
|