How do you know in advance if changing the behaviour of some procedure will break existing code? We don't have a full set of regression tests yet... and there are surely places where parts of the core depend on undocumented functionality of other parts of the core...
I guess my concern (not that I'm a commiter) is that any process that is put in place that can lead to people having commit rights revoked ought to be well defined and possible for *everyone* to live with *all the time*...
As soon as someone who has been smacked can turn around and say "well Lars broke X without issuing a TIP, why wasn't his access revoked" when the commit in question fixed an obvious bug whose behaviour happened to be relied on elsewhere, the process falls over. As others have said it's not feasible to require a TIP for every commit that could change the behaviour of a core API (this includes bugfixes), so making rules that require people to do so or face the most severe penalty possible in this sort of community will inevitably lead to inconsistent application of those rules.
I think my point is that you can't legislate common sense, and that looks like the aim of the rules suggested here so far. Common sense has so many corners and fuzzy edges that you'll never get it right, someone will feel wronged, and in practice you'll end up with a situation no better than the informal self-policing model that we have at the moment.
