[Haskell-cafe] helping you contribute to darcs (poll results so far)
Eric Y. Kow
eric.kow at gmail.com
Wed Aug 6 01:29:32 EDT 2008
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:
- GUI (david48, Bit Conner)
- splitting/merging (Luke Palmer, Ben Franksen)
- binary file handling (Jason Dusek)
- ... already does what I want (Allan Clark, Andrew Coppin)
- 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)
- 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
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
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
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
Size: 194 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080806/a4c62b79/attachment.bin
More information about the Haskell-Cafe