Simon Fraser wrote:
[EMAIL PROTECTED]">I'm not sure where the breakdown is here. if you're checking into the tree, you're looking at tbox (WAP/vxml tbox access isn't enough), and at the top of tbox is the text:I see a number of checkins today that have comments of the form:
Fix for bug 12345. r=foopy, sr=bazz
This is not acceptable. Checkin comments are not (just) so that
people can click links on Tinderbox and see what you did today
or yesterday, and click on a link to get to a bugzilla bug.
Checkin comments need to say what you did to the file and why.
They need to inform on the history of changes that have been
made to a file, in a way that makes sense without resorting
to looking in Bugzilla.
"Checkin comment should include the reviewer (e.g. [EMAIL PROTECTED]), the super-reviewer (e.g. [EMAIL PROTECTED]), a clear explanation of the fix , and the bug number. Reviewers and approvers are considered to be 'on the hook'! "
[EMAIL PROTECTED]">people not providing decent checkin comments should be required to debug code that has cvs revision history lacking comments ;-)How are we to encourage good checkin comments?
[EMAIL PROTECTED]">unfortunately, probably the latter :-/.Should part of
the review/super-review process include a review of the proposed
checkin comments? Or is a periodic knuckle-rapping, like this one,
sufficient?
Jud
