[darcs-users] David's darcs [Was: Re: darcs patch: ...]

[Eric Kow]

On Tue, Jul 21, 2009 at 18:08:19 +0200, Petr Rockai wrote:
> I know this has been lying around for a while. I took the time today to
> investigate in what shape David's darcs branch is.

Excellent, thanks for looking into this.

> (and I believe it does). However, doing "hard" merges, David's darcs now hangs
> even before asking for patches, making exchange of patches between
> hard-to-merge repos impossible (even for the easy patches). I believe this is a
> side-effect of the refactors and is something we would better wait to be
> resolved.

I think David would be interested to know if his branch introduces
a (potential) regression.  I think the ideal way to let him know
would be to present him with a before and after (both using his
branch only, ie. unpulling the refactor patches).  This eliminates
any confounding factors from our branch.  In other words, try to
make the job easy for him as much as possible.

> This basically means, that unless either of the darcsen fixes those exponential
> bugs (and the mergeConflictingNons one) that the branches are divorced.

:-(

I there's still a few things we can pull in, but in the long run it's
just going to get harder and harder.  That's good experience.  We have a
more concrete idea what kinds of things Darcs can't do: long lived
divergent branches.

I'll note that our two mergeConflictingNons bugs are marked resolved

 * http://bugs.darcs.net/issue1198
 * http://bugs.darcs.net/issue1043

Could you please open a new ticket? Hopefully in time, somebody will
have time to boil it down into a small test case as in issue1043.

That might also be helpful for David.

As for the exponential merge, without knowing for sure, I will guess
that this is us running into the limitations of Darcs 2 merging, and
won't be fixed until the Darcs 3 / Camp.  It would be nice if we
could study this in more detail, figure out what exactly is causing
the issue.  Trent said he ported some David patches over by hand, so
maybe it's just a conflict fight.  On the other hand, you have pointed
us to a non-conflict fight bad merge once.
 
> There are likely some choices:
> - abandon current darcs core altogether
> - try to fix it ourselves
> - try to merge David's work manually (and hope that he eventually fixes the
>   bugs in the core we care about)
> 
> I am starting to think that it would make sense (at least for me) to finish
> some work on the 2.4 release (with the current core), and then focus on moving
> along.

> The current darcs core is, unless major changes occur within the
> development team, as good as dead.

I propose we talk about this some more after Darcs 2.4 is out (I'd go as
far as to say after 2.5).  I'm assuming that by Darcs core you mean
roughly what is under Darcs.Patch.

Yes, we do have to be very candid about the fact that the current Darcs
Team currently lack the time and knowledge/experience to hack the Darcs
2 core.  But I think that to the extent that this is true, it is also
true that we lack the time and knowledge/experience to write a new core.
The most realistic routes are to outsource the work to the Camp project
and/or to get David back on the team (*).

I think we're agreed that we're stuck with the Darcs 2 core until at
least Darcs 2.4.  So far, we still think that Camp will need until Darcs
2.5 to have the proofs down.  I think it would be a good idea to wait
until the Camp Crew have a better idea on what their progress is before
we launch into any lengthy debates about what to do with the Darcs core.

The way I see it: we have a ton of immediately useful work we can do
in the Darcs.Repository and Darcs.Command layer right now, with our time
constraints and our skills.  Here are some examples:

 - more performance work: filecache and your current 2.4 work
 - polishing off the type witnesses work
 - separating the core/repo/command parts of the library
 - separating the user IO from the repo IO and other logic
 - fixing our handling of caches: http://bugs.darcs.net/issue1153 

I think this will keep us usefully busy for a long enough time that we
can postpone worrying about the core until we know more about where Camp
is going.  We just have to take a very patient, long-term, big picture
view on things.  Sure, the Darcs Team can't hack on the core now, but
can we do to transform ourselves into one that can?  How can we solve
the Day Job Problem?  I'm glad you're worrying about the technical
stuff, but I'm still wondering if we could be doing more, or doing
things differently to deal with the DJP.

Thanks,

Eric

[*] I think we just need to wait a (longish) while to prove to David
    that Darcs can manage just fine with some core decisions delegated
    to the community (eg. build systems, documentation), and also that
    when we get a lot of the infrastructure legwork out of the way
    (social and technical), we can make Darcs hacking fun again.

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20090722/848d0e2c/attachment.pgp>