[darcs-users] darcs roadmap proposal

Eric Kow kowey at darcs.net
Fri Nov 7 13:49:16 UTC 2008

Hi everybody,

We are now mostly caught up with the sprint work in the darcs unstable
branch (Reinier and Benedikt's work still need to be reviewed and sent
respectively), so I think it would be a good idea for us to set our
priorities straight for the next year.

 * 2009-11-15   GHC 6.10 support             darcs 2.1.1
 * 2009-11-30   build systems, libdarcs      darcs 2.1.2 
 * 2009-01-15   performance and Windows      darcs 2.2
 * 2009-07-15   performance and transplant   darcs 2.3

darcs 2.1.1 (2009-11-15) the GHC 6.10.1 release
I would like to see darcs released that compiles on GHC 6.10.1 very soon
now.  The safest bet would just be to tweak the current Makefile and
configure scripts accordingly.

I will continue acting as the Release Manager for this short-term
release.  We will going with a very short release cycle, one release
candidate and the formal release, as we expect to have no changes to the
actual code.

darcs 2.1.2 (2009-11-30), Cabal, libdarcs 0.0.1
I propose that we continue the 2.1 series with two more superficial

The first is to make the Cabal-oriented build system as a supported
build system alongside the current makefile (*).  Without David at the
helm, it becomes more urgent for us to enter into a tighter orbit with
the Haskell community.  The message we want to send is "we need your
help, and we will trust you to make the right decision on things which
we are not experts on."  This means adopting a lot of new standard
Haskell practices and making more use of external libraries where it is
safe to do so.  Note that the technical differences between franchise
and Cabal are not the main emphasis of this switch -- more on this in a
later message.  Both franchise and Cabal are meant to achieve the goal
of making darcs easier to build on Windows (and elsewhere), both us have
good ways of doing this (with pros and cons, which I shall detail
later); but one of the approaches has strong community support, and it
is the one we will be going with.

The second change is to make a very volatile and provisional libdarcs
0.0.1 available.  This consists simply of rewriting a few fields in the
Cabal file (and possibly creating a lightweight Cabal file for just the
darcs executable).  The purpose of this action is (1) to make a formal
commitment to working towards a proper libdarcs (2) to begin supporting
third party tools and encourage their developers to work more closely
with us.  The caveat is that because we have not worked out a reasonable
API to libdarcs, it should be considered both highly unsafe -- it eats
kittens -- and highly volatile -- it shall be eating kittens with
potentially a radically different API upon each release.  I think this
is acceptable as long as we make great pains to know what they are
getting into.

(*) It may be wise for us to keep the makefile and configure around
    for at least one more major release; we can revisit this in a
    later thread.

darcs 2.2 (2009-01-15) performance and Windows support
This will be the first darcs to be released under our time-based
schedule and with Jason Dagit taking over as release manager.

It will include some of the work we have done during the darcs hacking
sprint, basically some low-level optimisations and tuning of our data
structures to improve performance.  I also hope to see Benedikt's
filecache to make darcs annotate more usable in largish repositories,
and Petr's continued improvements to kill the darcs repair performance
regression that darcs 2.1 introduced.

There are also a couple of important conflict-handling bugs that
we uncovered during the hacking sprint, notably
 * http://bugs.darcs.net/issue1198
 * http://bugs.darcs.net/issue1204
Both of these are cases of darcs crashing in the presence of a
complicated conflict (it's a good thing darcs 2 has fully
atomic operations!).  I suspect that these are "just" bugs and
are relatively easy to solve.  So I think we should aim to have
these fixes in along with our Windows and performance work.

darcs 2.3 (2009-07-15) performance and darcs transplant
I'm sure we will continue to hack on performance after darcs 2.2 is
out, but I think it may be wise for us to shift the focus away from
it a little and get back to our core darcs work.

One major command that we should start thinking about is darcs
transplant.  We don't yet have a very clear picture exactly what
this command should do, but we do have an idea that it should
help people to (a) revise long feature branches (b) recover from
sins past or previous darcs corruption.  Basically, if you have
been longing for a way to amend or regroup a set of patches that
are dependeded on by other patches, darcs transplant may be what
you are looking for.
 * http://bugs.darcs.net/issue938

The idea is that while darcs commutation is most excellent, there
are times when it does not do everything we want

The future
There are some other long terms tasks I think we should undertake.
I'll just list them here

 * the DarcsLibraries project - spinning off as much of darcs code
   as possible into standalone libraries (pre-existing or otherwise)

 * patch theory improvements - Ian is working on further refinements
   to patch theory... these may become darcs 3 in the far future

 * improved conflict marking - This is something I, and many darcs
   users are longing for, though it will probably have to wait until
   Ian's work is complete

 * stable libdarcs

That's all!
Keep in mind that these are just my personal objectives.  Let's now
hear about yours.

Many thanks!

P.S. This discussion will be summarised in

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/20081107/6b4acde1/attachment-0001.pgp 

More information about the darcs-users mailing list