At Wed, 6 Aug 2008 06:29:32 +0100, Eric Y. Kow wrote:
Dear Haskellers,
patch theory is still not defined clearly or rigorously enough for Haskellers
Are the darcs developers familiar with these papers (available on citeseer): Undo Actions in Collaborative Work, Prakash & Knister 1992 Undoing Actions in Collaborative Work: Framework and Experience, Prakash & Knister 1994 The papers describe an undo mechanism for multiuser collaborative editing which sounds like how I imagine darcs patch theory to be (and, they even run into the dreaded exponential merge bug and propose a solution). They include some formal reasoning that may be easy to adapt to darcs? hope this helps, j.
Last Friday, I had posted a message asking how the darcs community could a better job recruiting developers to hack on darcs. Thanks for all the great responses! I am gratified by the suggestions you have offered, as well as the recent uptick in community involvement.
The responses so far fall along three themes: offering new features, improving code accessibility and shaking up the community:
Features - GUI (david48, Bit Conner) - splitting/merging (Luke Palmer, Ben Franksen) - binary file handling (Jason Dusek) - ... already does what I want (Allan Clark, Andrew Coppin)
Code accessibility - split into libs (Neil Mitchell) - unit tests! (Ashley Moran) - code documentation (Lele Gaifax) - patch theory docs (Apfelmus, Ferenc Wagner) - inherent simplicity of model, cf git (Austin Seipp)
Community - release announcements (Brandon Allbery, Neil Mitchell, Don Stewart) - showing ways to help (Wren Ng Thorton, Ferenc Wagner) - announcing our need for help (Wren Ng Thorton) - easier entry point to darcs code, à la xmonad (Petr Rockai) - more active leadership (Don Stewart, Lele Gaifax)
One thing which is clear is that the darcs team have failed to communicate effectively: the code is not as well-documented as it should be, patch theory is still not defined clearly or rigorously enough for Haskellers, the recent release announcements gave people the impression that darcs was being abandoned, and we haven't made it clear that we needed your help.
We need your help ----------------- Hopefully one thing is clearer after this discussion. We definitely need your help!
What we need most of all are some Haskell optimisation gurus to join the project, even in a minor way. Darcs 2 offers some huge improvements in safety and core efficiency. Unfortunately, these improvements are overshadowed by poor performance. Paradoxically speaking, darcs 2 just isn't fast enough for people to notice how much faster it has gotten! We need somebody to comb through our code and spot the silly things which are making performance suffer. Is there something too strict? Too lazy? Are going about IO completely the wrong way?
There is no patch theory needed for this! Anybody with an eye for performance should be able to rip into this code and find something to fix.
If you are not an optimisation guru, there are still loads of ways to help. For starters, you could help us to improve our support for Windows, or maybe some of the ProbablyEasy bugs:
We will communicate better -------------------------- The darcs 2 release announcement was very frank, but it also painted an inaccurate picture of the situation.
Here is a clearer picture: we are all still very interested in darcs and want to keep using it! If you have a large repository and you cannot wait for us to fix performance bugs, we wish you the best with git (etc). But if darcs can handle your repository, we hope you stick around.
It is true that David is taking a lower profile, but this just means that he is not following every discussion on the mailing list or every new bug and feature request. David is still receiving patches and reviewing them on a daily basis, providing the usual technical insight. So keep sending those patches!
That's all for now ------------------ I am going to leave things here for now, despite all the interesting points we could still address and see where else the discussion leads. In my next reply, I hope to address some of the more of suggestions you have offered.
Thanks again!
-- Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow PGP Key ID: 08AC04F9