This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: source mgt....[_HAS_ gcc relevance]
- From: dewar at gnat dot com (Robert Dewar)
- To: dewar at gnat dot com, lord at emf dot net
- Cc: gcc at gcc dot gnu dot org, torvalds at transmeta dot com, zack at codesourcery dot com
- Date: Wed, 18 Dec 2002 13:23:23 -0500 (EST)
- Subject: Re: source mgt....[_HAS_ gcc relevance]
> 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 :-)