incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: [RFC] commit-then-review vs review-then-commit
Date Wed, 16 May 2007 23:37:14 GMT
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.

Mime
View raw message