I agree with Simon, I just ran into this tracking down a regression and
it made the entire process take that much longer.
I think the bottom line here is there needs to be enough information in
a check in comment to understand why the file was changed, in case
further investigation is necessary.
At a minimum, one clear concise sentence shouldn't burden anyone (of
coarse a little more is better).
Rod
Simon Fraser wrote:
> 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
