[darcs-users] GSoC wrap-up mode

Jason Dagit dagit at codersbase.com
Mon Aug 3 14:39:52 UTC 2009


On Mon, Aug 3, 2009 at 6:54 AM, Petr Rockai <me at mornfall.net> wrote:

> Eric Kow <kowey at darcs.net> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20090803/646d2652/attachment.htm>


More information about the darcs-users mailing list