[darcs-users] managing change - lets have more tests
kowey at darcs.net
Mon Feb 16 08:34:38 UTC 2009
On Sat, Feb 14, 2009 at 13:02:19 +0000, Eric Kow wrote:
> 2. Likewise, I'm still reluctant to abandon the sunset process, but I
> think we can negotiate some sort of agreement on what kinds of things
> we will try to sunset and what sort of things we will let ourselves
> move faster on.
I've done some more thinking on this on the way to work, and would like
to slightly soften my position on sunsets.
Context: the current sunset process is
(1) new code enters, old code remains default
(2) new code becomes default
(3) old code stripped away
The purpose of this whole sunset thing is to help us discover bugs
before they become problems, i.e. allow them to appear in a somewhat
The new thinking is that step (1) of this process does not actually
contribute to this process very much, because nobody will try out the
new code. Therefore, I am willing to compress the sunset to just steps
(2) and (3) if we're still in the first two months of our hack cycle.
Furthermore, we could consider having a catch-all 'conservative' flag in
the build environment that keeps all the 'old' defaults in step (2).
People who value stability can just cabal configure -fconservative to
get the known working settings.
I hope this removes some of the tension around sunsets (the feeling that
one's code is effectively not getting into darcs) while allowing for the
sort of steadiness that I am aiming for.
The only thing left is the pain of maintaining multiple code paths, but
at least it's not for so long.
Anyway, this means that new code will now take 6 months to be released
(instead of 12), and old code will take 12 months to be removed,
(instead of 18).
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: Digital signature
More information about the darcs-users