I don't have an issue with retagging things before a notice gets sent to
testers to download a tarball, or with retagging the set of config files
needed to build the binary install, but in all cases the previously tagged
tarball should be deleted as soon as there is a perceived need for retagging.
However, none of this panic stuff would happen if the RM gives the developers
time to test the tagged repository prior to generating the tarball, either
by tagging and testing to be sure it is a good point of the tree or by
simply identifying a date-stamp, asking people to test CVS as of that
date-stamp, and then tagging that date-stamp (plus the few files that might
need fixing for a build). Or just tag the tree with a revision number,
branch on that tag, and either release it as is (if no fixes) or fix the
branch and release it as version+1 -- there is no reason why HEAD has to
be the only one tagged, provided that it is always merged back into HEAD
after the tag.
None of this is dogma -- we just have to balance the need to release
code on multiple platforms with the need to avoid blocking progress
at each release point.
....Roy
