On Mon, Aug 03, 2009 at 15:54:19 +0200, Petr Rockai wrote: > > - 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.
I'd like us to try reviewing it for at least one more month after the end of the project, see how things go and then adjust accordingly. > 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. I think we should be be doing this anyway. I still would also like for the hashed-storage code to be read and put through a traditional review. I realise it's been designed from scratch and has a nice battery of unit tests, which is really great, but this sort of thing is good for extra confidence. Once we've got through the initial review, we can rely more on the unit tests. *How* to get this review seems is a bit trickier. > > - 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 My votes: +1 on separating Darcs 2.4 being hashed-storage only (sans packing work) > 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. -1 on the compressed schedule I think it's best to stick to the schedule for simplicity and predictability. Releasing takes up time, energy and user attention. While I see the benefits of extra user testing (even at the expense of dog-fooding which you view as being not too valuable since the factory owners are too few), I doubt that the difference (3 extra months) is enough to justify the cost. That said, if we do decide to go for a quick 2.4, you're RM'ing it! ;-) (On the other hand, maybe this would be a good time for you to train your replacement). Also, if we go this route, we could perhaps decide to reset the clock after Darcs 2.4 and start releasing every six months from then. > 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). So this would be a natural -1 (from my earlier +1 on your plan A sans the compressed schedule) > 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. OK, so what would a reasonable schedule be for quick 2.4? 2009-09-15: all darcs-hs patches in mainline; freeze 2009-10-15: release? Is that enough time? Could we agree maybe to tag the darcs-hs stuff as if we were going to do a release anyway? > > - what kinds of stuff could a student work on if I was his/her GSoC > > mentor next year? > > This very much depends on where we are at that time. I would also be willing > to > mentor or co-mentor next year (as I don't expect to have time to apply as a > student). In case this wasn't clear from my first email, the 'I' was meant to refer to you (Petr Ročkai) as in, I was hinting that you should be a mentor next year. Glad to see you may be interested! -- 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
