On Mon, Aug 3, 2009 at 6:54 AM, Petr Rockai <[email protected]> wrote:
> Eric Kow <[email protected]> writes: > > - how do we smooth acceptance of hashed-storage patches into darcs > > mainline? > > One way would be to do a "leap of faith" -- just assume that the code is > good > and shove it in. This isn't very professional, but is probably better than > a > half-hearted review -- it's at least more honest. The other possibility is > to > find volunteers to review the code bit by bit, developing understanding of > the > underlying hashed-storage code. This is of course time-consuming and needs > the > said volunteer -- obviously, I can't be that volunteer myself. > > Another possibility is to write a function to go from Tree to a Slurpy. We > would also need to beef up the Arbitrary instance for Tree, but once there, > we > can pit treeDiff vs unsafeDiff using QC to generate inputs. I would be > reasonably happy to take this approach. It may be hard to coerce QC into > generating inputs suitable to actually stress the tree diff algorithm. My suggestion: These need not be mutually exclusive :) If you really have the time/energy to do this extra QC based testing, then please do it. > > > > - what's the work that minimally needs to get done for Darcs 2.4? > > Basically, I'd do away with unsafeDiff and then stick to some stabilisation > and > release 2.4 -- no extras, basically just reviewed darcs-hs as it is in two > weeks from now; this would mean that we stray from the 6-month cycle, but > we > could aim for a 2.5 to be 6 months from 2.3. I think I missed something. Why do we need to stray from the 6-month cycle? More importantly, which side would you err on, more time or less time? If you're thinking of bumping up the schedule, why not just use the difference (assuming it's at least a few months) as the stabilization period? > > > Alternatively, we could also aim directly for a bigger 2.4 in 6 months from > now, possibly including some sort of packing work (possibly as a separate, > experimental repository format). I would still prefer to do a quick 2.4 and > aim > for supporting experimental repositories as a goal of 2.5. -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. > > > 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. We may ponder a > little about allowing testing coverage to partially substitute for review. > I > don't know, really. I think it's still your call, since you are the > maintainer. > +1 for test coverage. Good work, good luck, and Thanks! Jason
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
