Alright, 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 controlled setting. 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
signature.asc
Description: Digital signature
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
