Now, remember that the principle in action here is "patch first, discuss later". Mental patched, now we're discussing. ;-)

We had another case like this earlier this week when some status bar functions were added that assumed use of global variables. The initial patch to the code appalled another developer, but by discussing it subsequently, good solutions were worked out.

That might be a good counterpoint, if not for one difference: you don't need anyone's testing when you remove something, because there's nothing to test. We don't need to try spiral-less Inkscape to discuss whether the spiral was good or bad.

In my case, I didn't remove anything, just added. And I raised the point on the list and in Wiki first, and committed my solution for testing later. Where I initially planned to remove something (namely the status_set signal), I did not go on until I heard from others on this change.

So while I do agree that discussion is *very* important, and in this case agree with you that the removal of the spiral should have been mentioned on the list, I would disagree that feature decisions _must_ be discussed before changes are made.

OK, what about a rule: feature DELETIONS (especially without a substitute) must be discussed on the list first. In the rest, I agree with you.

released version, so it was guaranteed that everyone would either notice it missing and start a discussion, or not notice it and prove it was unnecessary.

Well, I don't have the habit of inspecting the entire program every day to see if anything's missing :) So "not noticing" is by no means an indication that it's not necessary. Again, let's use a simple rule: do what you want, except _don't remove_ anything without discussing first.

Sorry for "freaking out". Hopefully we'll be able to avoid such collisions in the future.

_________________________________________________________________ Have fun customizing MSN Messenger � learn how here! http://www.msnmessenger-download.com/tracking/reach_customize