My main priorities, in no particular order: - fix the conflict problem once and for all - I'm very excited by the recent Pijul announcement and hope to be able to adopt the same approach for Darcs.
- develop darcsden as a good local UI as well as hosting platform - We've had some GSoC projects to help this along in the last few years. - develop my stash prototype and release it - with some UI work, I think this addresses the "switching branches" point below. - easy two-way darcs-git interop - we learnt a bunch of stuff when writing the original bridge, but need to start the imlementation again to get this right. - Patch groups (as below) - Improve rebase (including the items below) I tend to work on things in no particular order as and when the mood takes me, which doesn't really make for a great roadmap, I'm afraid! On 26/10/2015 15:04, David Leuschner wrote: > Hi Guillaume, > > thank you very much for dedicating so much time to Darcs! As you > probably know, we at factis research use Darcs for all of our projects > since about 2006. Stefan and I are very happy with Darcs and since we > have rebase there are no major shortcomings. Still it becomes > constantly harder for us to justify the decision to use Darcs in front > of our younger and newer colleagues, who have been using Git previously. > At the moment I don't really know what to expect from Darcs. The Darcs > development team is passionate and highly competent but very small. I > also don't know what the direction will be. What are the major > improvements you'd all like to work on? > > From the top of my head the perceived shortcomings of previous Git users are > - switching branches is not possible within the same directory (keeping > the directory is important because build products can be reused) > - there's no way to group patches ("feature branches") to be able to > treat them as a unit (for pulling/applying/suspending) > - there's no way to see at which time and by whom a patch has been > applied to a repository > - it's not as easy to refer to a specific state of the repository using > a hash > - when merging conflicts it's difficult to understand which part of the > marked conflict belongs to which patch > > Other frequent questions and wishes include > - Why can't I push to and pull from a repository with a rebase in progress? > - Why do I have to record all my changes before unsuspending a > (unrelated) patch? > - I'd like to explicitly swap to patches without having to suspend one, > obliterate the other, unsupend the first, reapply the other > - I'd like to undo unsuspending a patch > - I'd like to amend-record a patch that other patches depend on (without > having to suspend, amend-record, unsuspend) > > Thank's for taking on maintainership! We're always looking forward to > the next release! > > Cheers, > > David > > 2015-10-08 20:36 GMT+02:00 Guillaume Hoffmann <guilla...@gmail.com > <mailto:guilla...@gmail.com>>: > > Hi everyone, > > I guess I should say a few words about this :-) > > First I'd like to thank Eric for his work as a maintainer for 7 years, > and hope he'll stick around! > > For the observers that might wonder what is going to change for the > Darcs project, the answer is: not much. > > Ever since I started participating to Darcs (2009, my first sprint > attendance :,-) ), I found the project to be very collaborative and > consensus-lead. Anyone is welcome to send patches, code reviews are > public and are a great opportunity to learn about Darcs' codebase; > release management duties have been shared between several members over > time; coding sprints are open for participation, and indeed, every time > we have a few non-darcsers visiting us and helping. I am very happy > with these aspects of Darcs as a free software project, and Eric ensured > all of this happened over the years. > > So, things will continue as before! > > As for Darcs the software, how is it going to evolve? I cannot answer > this question alone for the long term. What I can say, is that in the > past I sometimes found Darcs' evolution as being a little too slow and > conservative. We lost valuable energy and focus in decisions which did > not pay off eventually. On some topics we did not reach any conclusion > and sticked to the status quo. My guess is that this drove a few hackers > to stop contributing, while the users also left anyway! > > I don't mean that we're going to break everything just to make us > developers happy. The very nature of Darcs leads us to be conservative: > Darcs is not just a software but also a data format (Darcs repositories) > which we don't want to change unless we have a *really* good reason > to do so. Also, Darcs handles other people's data, so we want it to be > safe and predictable. On the other hand, I think we should really commit > to the transitions we set ourselves to do, and remember that developer > energy is a scarce resource. > > Now for the short term, what is going to happen? We had a big 2.10 > release last April, 3 years after 2.8. It included a lot of new stuff, > which made us very happy; but the release process was consequently > quite long. I'd like the next release to happen sooner and I propose > myself to take care of it for a second time. The release process will > start after the GHC 8 release and the next sprint, which means February. > > Happy hacking! > > Guillaume > _______________________________________________ > darcs-users mailing list > darcs-users@darcs.net <mailto:darcs-users@darcs.net> > http://lists.osuosl.org/mailman/listinfo/darcs-users > > > > > _______________________________________________ > darcs-users mailing list > darcs-users@darcs.net > http://lists.osuosl.org/mailman/listinfo/darcs-users > _______________________________________________ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users