[darcs-users] managing change

Stephen J. Turnbull stephen at xemacs.org
Sat Feb 7 00:59:20 UTC 2009


Eric Kow writes:

 > So despite my claims, it's not even completely clear that the so-called
 > "conservative" sunset procedure is the sort of responsible engineering
 > practice that it aspires to be.

Logically it's ambiguous.  Empirically, the sunset procedure wins.
Projects that think their users are happy with a reasonable amount of
instability are probably correct, but that's because they don't have
any of the users who value stability.  There are a lot of those, and
you want to support them, I guess.

Also, by the nature of things platform support in external modules is
going to be uneven.  A lot of code is just going to have to be
maintained until the external libraries catch up.

 > For example, as Petr might suggest, instead of doing things in
 > three 6 month stages, we should compress it to one stage and count
 > on people using the unstable version to catch errors.

In practice, this doesn't work.  This is one reason why Emacs has lost
so much mindshare over the past decade, why SXEmacs hasn't gained
much, and maintenance of a very stable version is almost certainly why
XEmacs survives.  The rationale is that people using the unstable
version are almost by definition advanced users, and probably also
have a fairly common culture about how to use VCS.  You're just going
to screw the ordinary users.

 > Test-driven development : a new way forward?

It's a good idea, a *very* good idea, but the projects I really
respect (for other reasons ;-) use both a sunset policy and
test-driven development.

N.B.  The big advantage of sunset policy is that a maintainer can
enforce that himself, and maybe even himself handle a lot of bit-rot
as it happens, while test-driven development will definitely cost you
a lot of your contributors, possibly some of your more prolific, even
some of the best programmers, because it becomes more effort than it's
worth to them.

 > > I don't think bugs will take a long time to get fixed. We should
 > > be forced to fix our own bugs, instead of giving ourselves easy
 > > ways to avoid them by compiling with different options.

Test coverage is indeed important, and reducing the number of code
paths does help improve that, a *lot*.  On the other hand, buildbots
are fairly cheap to add, though require discipline to maintain.  But
some bugs *will* take a long time to get fixed, because they take a
long time to appear, or because traditional "good" coding practice
blows up in the face of changes in implementation language or
compiler, or external dependencies.  This does matter, because both
kinds are likely to be very hard bugs to fix.

Tests are likely to be buggy (especially by being incomplete).

And some "bugs" are other folks' "features", etc.  But you already
know how to deal with that.  It's just another way in which
test-driven development is not a panacea.

 > 3. It seems that for a heavy reliance on testing to work, we are going
 >    to need to have much much wider test coverage.  How do we break out
 >    of this chicken and egg?  Do we put everything on hold and launch a
 >    massive darcs testing initiative?

I don't think so.  A lot of things you need to test just take a lot of
time and effort to create tests for.  Delaying everything for the test
effort will just drain out a lot of enthusiasm of people who really
want new features.

 >    Do we compromise and spend half our energy on testing, and the
 >    other half on doing new stuff?  It might be sensible.  More
 >    tests could just mean faster progress.

Not for all contributors, though.  There are a lot of contributors who
really do want to fire-and-forget their patches, but many of those can
be convinced to do better quality control.  You are going to need a
stick of enforcement to go with the carrot of faster progress.  (Of
course any policy imposing burdens on contributors must show faster
progress on a widely agreed metric or it's dead in the water.)

You personally can help that along by regularly asking for
tests, and fast-tracking patches that improve the test suite, and
randomly delaying patches that don't come with tests while waiting for
somebody (including yourself) to write the needed tests, etc.  (For
the last strategy to work you have to be scrupulously fair, and you
really should write a lot of tests yourself at the beginning to
demonstrate that it's about writing tests, not about demonstrating
your power.)



More information about the darcs-users mailing list