[darcs-users] managing change

[Dan Pascu]

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