[darcs-users] managing change
Stephen J. Turnbull
stephen at xemacs.org
Sun Feb 8 00:46:11 UTC 2009
> 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.
Twisted is a different case, though, being a commercial product with
programmers paid to work on it. That gets them through the dry period
when people are changing their habits and releases slow down.
There's a programmer on another list that I read who refuses to submit
bugs and patches until the tracker implements OpenID. He's stuck to
it so far, too, despite several personal invitations to contribute.
So I think you'll probably find a pretty large turnover of
contributors if you make this a hard requirement.
> 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.
Yup. The question is, does Darcs have enough momentum to get through
the culture shift. I think it's a good bet ... ie, it will probably
pay off handsomely ... but it will be costly to kowey, especially, and
you'll probably see the community turn over a bit. And there is some
risk of long-term damage to the project's pace of development.
> Maybe it will [turn people off], and maybe you should be willing to
> abandon it if it looks like it doesn't work,
That's always true, but for this change, probably the bite-the-bullet
phase will last quite a while....
> but really a revision control tool should be ideally suited to
> automated, thorough testing (in contrast with a sprawling network
> and language framework like Twisted, which should be very hard to
> automatedly test), and Haskell ought to be uniquely well-suited to
> automated, thorough testing.
I'm not so sanguine. It will work, and it will be easier than
Twisted, but "automated thoroughness" is IMO an oxymoron (at least
until patch theory is much better founded than it is now, ie, it takes
language semantics into account) and it's not clear to me what makes
Haskell suited to testing when the whole point is compile-time rigor.
More information about the darcs-users