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. > - 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. 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. 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. > - how can I make it easy for us to continue working on darcs with > hashed-storage at a much slower pace (i.e. without the benefit > of a full-time darcs job?) I believe a lot of infrastructure work has landed that should make things easier. I will mostly keep working on hashed-storage and darcs-hs, trickling patches down to mainline. This seems to be a low-stress way to get patches through without blocking on review too much. If we adopt the commit bit approach, I would probably welcome a system, where people would only push patches that they are not authors of. Basically, this would just streamline the current process: someone reviews a patch and then pushes it into mainline, instead of telling you to push it. 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. > - 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). One area would be to work on patch application code. Another would be to work on better patch formats, as an experimental repoformat (for which we should have the infrastructure ready by the time). But we have enough time to think this through, and also we'll see how and where we are with our winter (sorry Trent) release. Yours, Petr. _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
