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
