Well there were lots of good ideas and different perspectives which I hadn't considered. For one, I didn't realize that the core API was changing so rapidly. Most of the packages I have written have worked unchanged for the last several years, maybe with the exception of the context bar.
So first off, I think my idea of what the core APIs include isn't as broad as what is actually in the core.
Second, my proposal wasn't to stop _any_ change or coding from taking place. The main ideas, maybe poorly communicated, were:
- that there should be a central place where the reasons
for the changes are recorded. Maybe explaining the changes so that folks know what to expect, without looking at a cvs log and piecing togeather that with the original file.
- that the OCT take active oversight of these changes. Maybe that means something as simple as reading about the changes. Since cvs is always there to revert changes, my main concern is that a change, which is not good, goes in to support a package, unintentionally breaking other packages. Once another package needs this change, it is hard to use cvs to fix the matter.
- Someone reviews the code for core changes. I think the rules and responsibilities TIP had some ideas about that. The package maintainer needed to review patches before they were used on the core.
- The TIP process is finite. Discussions on what changes should take place that happen on the regular forums are not. If someone gets tired of talking about what they are going to change, and they have commit rights, they can just stop and make the change anyway. A TIP makes the decision process understandable to everyone, and it gets multiple views into the discussion. Regular forum discussions usually only involve a few voices, and maybe not the most knowledgeable ones on the subject. I know that after reading this TIP, my opinions have changed and my understanding of the issues have expanded. My opinion: this is the point of the TIP process. One or two, or even three dissenting voices isn't going to stop a change.
Third: revoking commit rights should always be possible. It should be as easy as getting them in the process. But this would probably be rarely applied. I didn't see it as harsh because I didn't imagine that it would happen very often. However Jeff's points are good. Maybe this is too heavy a stick and it could be used as a punishment. Removing commit rights is something that can be dealt with completely separately from the main issue of documenting core API changes.
