tag:blogger.com,1999:blog-3881428479518553465.post4249222471809375988..comments2009-02-25T16:02:19.091-06:00Matthew Kinghttp://www.blogger.com/profile/03223931423148258501noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-3881428479518553465.post-20894274766193468602009-02-25T16:02:00.000-06:002009-02-25T16:02:00.000-06:00I'm working on it, or at least worrying on it.<BR/><BR/>Yesterday I joked with some colleagues on IRC that RubyGems should have an --im-feeling-lucky flag that installs the gem from the GitHub repo with the most recent commit. Listing off the reasons why that's a bad idea is a good introduction to the problem.<BR/><BR/>Other questions:<BR/><BR/>What other criteria are important in determining which incarnation of a project one should use? <BR/><BR/>How do we distinguish between forks and collaborations in the age of distributed version control?<BR/><BR/>Some ideas:<BR/><BR/>Only canonize the test suite. This still requires some Benevolent Dictatorship, but the duties will be less onerous.<BR/><BR/>For GitHub, treat the fork network as a graph, not a tree. Find some way to determine which forks directly use commits from other forks. Allow each forker to set a "primary" node preference other than the repo they forked from.Matthew Kinghttp://www.blogger.com/profile/03223931423148258501noreply@blogger.comtag:blogger.com,1999:blog-3881428479518553465.post-76277744515241105752009-02-25T11:52:00.000-06:002009-02-25T11:52:00.000-06:00You've made a good case for the problem. Is there a solution? Is anyone working on anything to address the problems associated with centralized distribution of projects?jamisbuck.orghttp://jamisbuck.org/noreply@blogger.com