[darcs-users] darcs roadmap proposal

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 changes. 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 http://wiki.darcs.net/index.html/Roadmap -- 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