source mgt....[_HAS_ gcc relevance]

[Robert Dewar]

> A lot of the thinking behind arch is to scale up and simplify adopting
> practices such as you describe so that they are applied by default to
> pretty much all of the free software (and "open source") projects in
> the world.  With your 35, you have social pressures and the power of
> the employer to enforce restrictions like "run the tests before
> committing to mainline" -- but wouldn't it be nice if that were
> automated: so a developer could hit the "try to test and merge" button
> before going home for the night, coming back in the morning to either
> a commit email or a list of test failures -- and if you _didn't_ have
> to write all your own tools for that automation because they were just
> there already, such that setting up a new project with these
> properties was as easy as creating a project on Savannah currently is
> (or, easier :).

Yes, indeed, automating requirements like this is always desirable.
Although you probably want ways to override requirements in emergencies.

What we find is that the key point is that it must be *easy* to follow
procedures, if it is, then they get followed, if not, no amount of
social pressure can guarantee conformance :-)