I think communicating such changes is important and
not changing things without a consensus is also
quite important but I think the current machanisms
for oversight are reasonable (longish beta periods,
nightly builds, commit mails, the cvs log browser's
RSS feed, and the existing forums and irc).
Formalizing this for the core API makes sense to me
but for a proposal like this to be acceptible we would
need to be more careful about having things labeled private
and public (and would need to add an experimental attribute
to make clear that certain APIs were still open to change
w/o the onus of writing a TIP). In addition I think
"changing an api" would have to mean causing existing
unit tests to fail (and of course such unit tests would need
to be written...). As it stands, generally there are no
unit tests to define current behavior and so the expected
behavior is implicit in the way the APIs are used (and
sometimes explicit in the documentation -- although there
are enough conflicts between the code and documentation
that even that is not really a good way to define
expected behavior).
In any case, I find the penalty overly harsh and prone
to capricious or contentious revocation of commit.
Revoking commit for someone should be carefully considered,
be the consensus of the OCT, and
should never be up to one person (you need only look at
times it's happened in other open source projects
to see the potential repercussions). I would strongly
object to any element of project governance which would
allow something like that to happen.
