Certainly from my perspective it makes sense for darcs to tackle some of the more academic projects and crazy feature ideas solely because it is just about the only source control system to be in a good position to do so.
As to this particular proposal, I would be interested to see what becomes of it. If I may offer suggestions, I think this would be a great opportunity to also bring in work from elsewhere in the theoretical space (such as some of the hubbub from the Operational Transforms world). In fact, I would suggest that maybe a better prototype than just using normal file merging in darcs would be to build a real-time example using JSON objects and built on something like share.js (http://sharejs.org/): then extrapolate down into how darcs would handle that flow. Maybe there might be some interesting lessons from libraries like share.js that could apply to darcs. Maybe the JSON-based approach of web OT libraries might provide insight into the possibilities of more generic document stores for darcs... Sent from my wireless telegraph. Full stop. ________________________________ From: Eric Kow<mailto:ko...@darcs.net> Sent: 3/21/2014 11:38 To: Vikraman<mailto:vikraman.choudh...@gmail.com> Cc: Darcs mailing list<mailto:darcs-users@darcs.net> Subject: Re: [darcs-users] RFC: GSoC proposal: Distributed Issue Tracking in Darcsden Hi Vikraman, (I'm afraid I don't have feedback for you specifically, but just general musing on GSoC) Exploratory proposals like this are cool in that they explicitly put Darcs in the interesting-research realm of version control (aside from being a usable system with a friendly UI). We have some experience doing exploratory projects (Petr's primitive patches 3 work) >From a practical standpoint, I'd be a bit nervous about whether or not we could deliver an actually usable issue tracker, and whether we would want to maintain something like a darcs issues in the codebase; on the other hand, part of me thinks that it'd be good for Darcs to wholeheartedly embrace its Out-Thereness and dive into projects like this. For example maybe the work on trying to fit an alternative set of patch commutation rules would force us to discover lots more interesting holes in patch theory (or at least force us to reorganise, refactor, clean up the Darcs library even more). So what do people think about exploratory GSoC projects? All other things being equal, how do we want to allocate things? Should we focus on short-term achievable bits of progress (to darcs and the ecosystem in general). Or should we develop a general project framework for letting our freak flag fly? On 21 March 2014 14:44, Vikraman <vikraman.choudh...@gmail.com> wrote: > Hello everyone, > > I am proposing a GSoC project with darcs. The idea is to improve the > issue tracker in darcsden, by implementing distributed issue tracking > using patch theory. Any feedback is welcome! > > You can read my proposal in markdown here[0], and a pdf version here[1]. > > [0]http://hub.darcs.net/vikraman/darcs-gsoc-proposal/browse/proposal.md > [1]http://dev.gentoo.org/~vikraman/misc/darcs-gsoc-proposal.pdf > > -- > Vikraman > > _______________________________________________ > darcs-users mailing list > darcs-users@darcs.net > http://lists.osuosl.org/mailman/listinfo/darcs-users > -- Eric Kow <http://erickow.com> _______________________________________________ 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
