Phillip J. Eby wrote: > Pre- and post-commit scripts, and some modifications to the build and > test processes to track the SVN revision being built, to associate error > logs with specific tests.
Ok, I can see how the tbox script could be enhanced to for example send email to all people who committed changes for this cycle. Some parts of this are a little tricky, and some more or less impossible: - when restarting from scratch there is no information to determine what changed in this cycle (actually, everything changed). maybe we don't care about automating this edge case - there's nobody to make sure that people actually act on the email, or that they even are there to read the email in the first place (I would expect the sheriff to call if there is no response to IRC or email ping) In any case, it would be nice to make it easier to get the error logs and notifications. > I doubt the actual implementation will be complex; the hardest part is > probably standardizing on a commit message template or format. By > which I mean the hard part is getting everybody to agree on it, not its > actual implementation. :) I agree. We already have a guideline, but some people are not following it - sometimes by accident, sometimes systematically because they disagree with the guideline. Even though I am generally process-oriented, I am not so sure I would want some script prevent me from committing because of some format issue in the commit log - what if the script is simply wrong for this particular instance? > (Actually, it's even crazier than that. Apart from Tinderbox > monitoring, It sounds to me like we're talking about having a rotating > duty to keep an eye on everybody else, instead of having people be > responsible for doing their own good work *every day*. That sounds to The only part that sounds like keeping an eye on everyone else is checkin that the commits follow the guidelines and are correct. And even if we could actually get a commit message format checking automated, I think there are some parts of that that can't be automated IMO: * Although maybe theoretically possible, it seems like a far stretch to say the script can check if the checkin type was allowed (for example, only blocking bugs + comments + docstrings on 0.6 branch where blocking bugs need a bug number an a reviewer). * I don't see any 100% reliable way to check that the bug number was actually correct. * Did the checkin comment actually explain anything, or was it more or less just some filler to get past the format checker? If we assume people won't make mistakes and want to do the right thing then these wouldn't be issues. But at least mistakes will always happen. Btw, note that we already get a failure message on IRC. In my experience people ignore them. Maybe they wouldn't if the message specifically mentioned their nick. Also, Tinderbox very prominently states when the tree is closed. You are supposed to check Tbox before checking in. And bear also sends out email. Yet we still get a few checkins when the tree is closed every now and then. -- Heikki Toivonen
signature.asc
Description: OpenPGP digital signature
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
