= > Communication should be done via a package-specific mailing list. The = > maintainer of the package decides who has commit privileges for this = > package and who gets on this package's developers' mailing-list. = = The way we are currently doing it here (at Pixar) is that nobody checks = in an un-reviewed patch, even if they do have commit privilege. Anyone = with commit privilege can review it for you and give you an OK to check = it in, but it takes two people. It tends to make us think a bit harder = about what we are doing.
There are advantages to commiting intermediate versions and un-reviewed patches. The redundancy is a good idea - you won't lose all your work if the disk crashes or somebody does 'rm -r /'. But perhaps a bigger advantage is anyone anywhere with CVS access can use 'cvs diff -rSTABLE' to review the changes -- they don't have to depend on you preparing a 'diff' e-mail or something. They can even check out the trial version to build or test or even compare your changes to their changes. The "final" commit is done by moving a tag or potentially moving something to a "stable" branch. This can be on the honor system since CVS doesn't have per-tag access control (that I know of) with audit possible (I think) through the CVS log files. Obviously all "official/stable" release/builds occur from the STABLE tag. -P -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .