Dear Eric Kow: Your explanation of the motivation for your policy makes sense. It sounds like you have the right motivations.
I just wanted to mention that there is another technique along with "don't change things" which can offer good stability to users. That is: "Don't change things unless the functionality and the code being changed is thoroughly covered by automated tests.". This is the policy of the Twisted Python project, and I have watched them for the last couple of years and it has worked out well for them. When contributors submit patches which add functionality, those patches are not accepted until they come with thorough tests exercising every aspect of the new functionality. When a patch is submitted which refactors code, it is not accepted unless the new version of the code is thoroughly exercised by the tests. If a patch offers to fix a bug, it is not accepted unless there is a test which exercises the bug -- failing with the current code and passing with the new code, as well as having good code coverage as measured by a line-by-line code coverage measurement tool. I have grown so used to this style of development that when I see open source projects committing patches that change their codebase *without* accompanying unit tests I kind of get that mildly alarmed feeling as if I'm driving a car and then realize that my seat belt isn't on. :-) Regards, Zooko _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
