[darcs-users] managing change

[Trent W. Buck]

Just some miscellaneous thoughts...

Eric Kow <kowey at darcs.net> writes:

> Ugly sunsets
> ============
> What we are talking about here is making any sort of major change which
> has a risk of breaking darcs.  Mostly it means getting rid of some old
> code and replacing it with some external module.  The approach I am
> defaulting to, is a conservative Sunset Procedure, rolling things out in
> stages (major darcs releases), where at each stage
>
>  - make the new code available through conditional compilation
>    defaulting to the old code

As the new code is not the default, does this really need to wait for a
major release (or could it fit into a minor release)?

> maybe I have it all backwards, in the sense that they only way we are
> going to discover the flaws (test-driven-development aside) is to
> expose the new code to a wide audience as early as possible.
> For
> example, as Petr might suggest, instead of doing things in three 6
> month stages, we should compress it to one stage [...]

Is it acceptable in the one-stage method to simply say to users "if you
have problems, downgrade to the previous release, and wait for us to fix
it in the next release" ?

People who really care about stability seem to already be several major
releases behind the latest -- some people are still running darcs-1
format repos for this reason!

>> Instead of keeping things around in case "something breaks", we should ask new
>> code to come with test coverage [...]
>
> 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?  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.

I agree with Petr's by-attrition approach: old code doesn't need
rigorous tests, but new code (particularly sweeping changes, e.g. to use
a new external library) *does* need rigorous test code.