It is now clear that darcs-fastconvert shall be taken under the darcs umbrella and enjoy the project's infrastructures. Max and Florent, suggested that we provide binaries for darcs-fastconvert along with darcs. As Eric said, it's up to the release managers and packagers to decide that and see how they want to package the bundle.
Now, Petr's suggestion is to separate darcs-cmdline from libdarcs, and make darcs-fastconvert provide a libdarcsfastconvert API. Then darcs-cmdline will be able to depend easily on libdarcsfastconvert. This is very seducing but the big question is: how much work is needed to separate darcs-cmdline from libdarcs? Should we commit to that goal as soon as possible? After the codebase has read-only OF support? We don't agree about what to do with FC, but it's fine since it's not the right moment to include it in darcs anyway, if we want to avoid codebase growth before engaging major refactoring. So what about this roadmap? 1. separate darcs-cmdline from libdarcs 2. in parallel, Petr provides libdarcsfastconvert 3. when both are done, we put the topic back on the table: shall the darcs commandline UI come by default with its subcommand ``fastconvert`` ? Is it time for a thread on darcs-cmdline/libdarcs separation? Guillaume ps: FC could indeed be a plugin, but because of the reasons I said, it is much more important than, say, a Musdex plugin. Max, maybe you want to start a thread on plugins? (possibly with a wiki page to detail a proposal?) (I'm certainly not against seeing a Musdex plugin happening!) ps2: Florent said that FC should not be a ``convert`` sub-subcommand. Fair enough, we could use ``darcs fastconvert``, just as all the ``git-subcommand`` executables became ``git subcommand``. _______________________________________________ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
