stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject [RFC] commit-then-review vs review-then-commit
Date Tue, 15 May 2007 15:30:10 GMT
Our recent status report raised a question from one of the reviewers
about our commit policy, specifically about the following comment on
it on our project page:

   Except where noted, all stdcxx committers follow the Review Then
   Commit policy.

 From the stdcxx section of the Wiki page:

   iPMC Comments:
     * jukka: I'm qurious about
      Why some people are following CTR and others RTC?

I thought it would be useful for us to discuss and clarify our policy
with respect to commits.

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. 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

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.

Does this sound reasonable to everyone? Are we ready to have
a vote on this proposal?


View raw message