On Sunday 08 February 2009, zooko wrote: > I was concerned about this during the first year or so after Twisted > Python launched their new "no exceptions" policy that every patch had > to come with thorough testing of all the code that it touched. The > policy that came into effect, dubbed The Ultimate Quality Development > System, also mandated that every patch thoroughly documented the code > that it changed and that every patch was reviewed by someone other > than the author to certify the first two requirements. > > I started to fear that, even though the Ultimate Quality Development > System was good at forcing the codebase to be monotonically less > buggy, that it might accomplish this by there never being another > release of Twisted after the policy came into effect. :-) > > However, eventually releases of Twisted started up again, and now > progress seems to be steady despite the iron hand of the Ultimate > Quality Development System blocking untested or undocumented patches > from landing in trunk. I think part of what happened was a culture > shift -- after a few months contributors got used to the idea that > patches just really weren't ever going to go in until *someone* wrote > tests for them, and they got into the habit of writing tests for the > patches they cared about.
Let's not forget the context of this. When it started this policy, twisted was already a very successful and widely used framework. In other words it had a big momentum. The alternative for the contributors would have been to: 1. Comply 2. Not see their bug fixes/changes in twisted ever 3. Switch to a different framework. I can easily see that option 1 was the cheapest alternative, even though it felt like being forced on them. I'm also sure many resisted it for quite a while. Now this policy would be a completely different story if applied to a new project you just started. I can guarantee that you will be the only contributor to your project for a very, very long time. Only when it will gain enough momentum, will people start to overcome the restriction and contribute. Another point of view, is that there are many more Python programmers out there than Haskell programmers, which makes it much easier to find new contributors for twisted after some were driven out by the policy, than it would be to find new Haskell programmers if some darcs contributors leave. In the end I think the whole point of this is to correctly evaluate its impact in the specific context where it is applied, so it won't kill the goose laying the golden eggs. -- Dan _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
