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.

How are we to encourage good checkin comments? 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?

Simon

Reply via email to