Re: new darcs maintainer: Guillaume Hoffmann

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 <[email protected]
> <mailto:[email protected]>>:
> 
>     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
>     [email protected] <mailto:[email protected]>
>     http://lists.osuosl.org/mailman/listinfo/darcs-users
> 
> 
> 
> 
> _______________________________________________
> darcs-users mailing list
> [email protected]
> http://lists.osuosl.org/mailman/listinfo/darcs-users
>