Jason Dagit <[email protected]> writes: > -1 to a quick 2.4. Lots has changed, right? I say we give that a chance to > be > tested in the real-world a bit. I think we should be prudent here. Your work > is more than simple refactors and bug fixes as I understand it. You wrote a > lot of new code/abstractions. So I think the prudent thing is to dog food > that > for a while till we have internal confidence, then push it out to the world.
That's relative. Most of the code is currently employed by 2.3 in the whatsnew path. There's very little other "new" stuff in darcs-hs -- bulk of this is just one-liners flipping things from unsafeDiff to treeDiff. As for internal confidence, where would that come from? I mean, I am using darcs-hs as my main darcs for over a month now. Daily usage for two months or five, by one or three people is not much of a difference. My argument here is, that all that extra time will cause is sloppy review, since people will say "oh, but we have 5 months to test this, so we don't need to pay so much attention". I reckon that the net result with longer schedule will be worse than with short schedule. Don't worry, I don't mean to rush things. But I would like to work further, and I feel that lumping twice as many things in a single release is not going to be any easier. However, waiting six months to get things into mainline because "we already have lots of things for 2.4 that's due early next year" would be probably quite demotivational. > There are relative merits to both approaches. What I don't like about > waiting six months for integrating darcs-hs into a stable release is that > it gives us too much slack time. We will put things off because we can > and then do a poor QA job, just because the thing will be old by then. > > Random thought: > I say we should have an unstable branch and a stable branch :) Leave darcs-hs > out of stable for now, and keep working on and testing the unstable branch. > I > doubt this will be popular, but it seems reasonable to me considering we seem > to have two competing goals. It seems like there is 1) the goal of providing > the same stable darcs that we have been providing; 2) the goal of stablizing > darcs-hs. Likewise, I think that'll just provide us with more excuses. We either are confident in the code, or we are not. I don't buy the argument that waiting arbitrary number of months is going to make us any more confident in the code. We have been collectively using darcs-2 core for what, a year now? Yet, I am not any more confident about it than I was at the beginning. I would rather see people actually taking action and poking the code actively wherever they don't feel confident about it. But if they don't do that if given 2 months, will they if given 5? Hard to tell, but my bet would be on "no". (We know how to poke at darcs-2 core to make it fall apart. But unlike the darcs-2 core, if you find ways to break hashed-storage, I will go and fix it so that it won't, which will translate into a better release.) Yours, Petr. _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
