Hi all, * Peter Bex <peter....@xs4all.nl> [110303 09:32]: > I've written up a proposal for switching our egg repository to > a distributed type of deal: > > http://wiki.call-cc.org/distributed-egg-repos > > Since many users have indicated they are very much fed up with > svn and would prefer to use $FAVORITE_VCS (and some of our existing > developers are already doing so, mostly ignoring svn) I think this > deserves some serious consideration.
I have carried around various thoughts on this matter for a long time now. I hope they are ready for public consumption. Let's restate the pro's of Peters approach: * Proper usage of version control * Distribution of the permission bottleneck * Lower barrier of entry * Reducing checkout and repository size and the cons * Broken links & dependencies * Documentation * Additional complexity I would like to adress some fears people already expressed and propose a a bit more than Peter did in his original proposal: Previously some folks mentioned that a DVCS means looser coupling between the 'official' egg repo code and the DVCS contributions with all the risks of being unmaintained, unreachable, converted to python etc... In my little world this can be caused by: * maintainers leaving * stalled development (either WORKS FOR ME or obsolete-d-by-next-hype) * collapse of infrastructure, (sourceforge changed policies, github sold out, etc) * death of domain (spammers taking over, unpaid bills,...) I think the only way to get a grip on these issues is to have a centrally maintained repository or trust other parties to ensure the availability of code. Documentation: At least at the moment I cannot see a drawback in that in either solution. Either the author cares and provides documentation or he doesn't. We do have poorly documented eggs in the repo at the moment and we also received nice documentation from contributors with external main repositories. Additional Complexity: This is also a no brainer, whichever way we decide to go, we will have to change things in the long run. Either to adapt to the larger SVN tree or to the new scheme. Both may be done without breaking existing stuff (apart from path changes of course). So I think the only remaining hard drawback is the looming doom of unmaintained code that I as another egg author would build on my own egg or depend on it as a application developer in my job. So why bother? Because the good parts are really good. Lower entry bars is great! Not restricting people to a certain workflow is also great. I don't mind the checkout size of the repo that much, maybe we can find ways to deliver a functional checkout with some technical helper? But the first two points are the key. I am just not sure if the solution is the right one because of the BROKEN LINKS[tm] scenario. What about the following sketch of an alternative: - Abstract the installation process through the henrietta script as proposed. (I really like this idea). - Automatically *mirror* the contributed archives on call-cc.org, maybe after the code has passed N salmonella rounds of master and experimental branches. - Keep the documentation in the wiki as it is. I envision this mirroring stuff simply as a means of the contributor adding a repo url or something similar to the repo with a branch of it being defined as 'release' or 'stable' code. Then the magical script will pull it in and schedule it for salmonella, mailing back all rrors it finds. After some rounds it is accepted and actively mirrored and registered with henrietta. Of course this also comes with a price tag in terms of our time and effort to get it up and running smoothly. I do think this allows us to combine the best of both worlds though. From perliminary research I beleive that quicklisp works according to this principle. And if there is something new in the lisp library world, it is a central archive and distribution channel. We already do have this advantage, so why not open this up a little for decentral contributions? Thanks for reading this far. I hope I was able to give you a coherent dump of my thoughts on this. May it fertilize the further discussion. Kind regards, Christian _______________________________________________ Chicken-hackers mailing list Chicken-hackers@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-hackers