[darcs-users] GSoC wrap-up mode

[Petr Rockai]

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.

>  - 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.