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.) _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
