On Mon, Nov 24, 2008 at 9:33 AM, David Abrahams <dave@boostpro.com> wrote:
on Sun Nov 23 2008, "Daniel Walker" <daniel.j.walker-AT-gmail.com> wrote:
One of the reasons Boost exists is to be more nimble than any committee (particularly the C++ standards committee) can be.
That's true, but at the same time, one goal of boost, as I've understood it, is to establish existing practice, which could eventually lead to inclusion in the standard library. So, yes, boost should be more nimble than the ISO, but I think it should not be so fluid as to make the peer review process meaningless and undermine progress toward establishing best practices.
Do you actually think the current peer review process is meaningless, due to the fluidity of our operations?
In general, no, but in this specific instance, yes. At least, the Range concept definitions in the initial release immediately following the formal review are richer and more useful, IMHO, than the definitions available in the current release.
I wish I could get someone to just start composing a page of best practices without jumping headlong into trying to impose constraints on our contributors. We haven't even tried making such guidelines available yet.
You're right. I just think of permissions on a version control system as a tool, more than a negative constraint, so that's the first idea I had. If more conservative changes to test cases are a result of self-discipline, which I often lack ;), or if it's computer aided, either way, it's probably a good thing.
I guess I don't think it would be unreasonable to ask the release managers, as guardians of release quality, to monitor changes to the tests when they are checked into the release branch.
Yeah, that's a good idea. And as you suggested before, if SVN/Track can help by sending e-mails, it might make the release manager's life easier. Daniel Walker