Re: Using CVS for package development
= > 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.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
email@example.com . Trouble?
e-mail to firstname.lastname@example.org .