On 09/03/2010 19:37, Michael Richardson wrote:
"Chris" == Chris Travers<..hidden..> writes:Chris> As we move more to an addon-centric model, it seems to me we Chris> have two choices: Chris> 1) We could recommend that addons get their own project space Chris> on sourceforge, etc Chris> 2) We could move to a dcvs and if Chris> Sourceforge does not provide sufficient permission management Chris> facilities, move elsewhere. Chris> What to folks think? Both are required. The system must come with a rich set of plugins/addons out of the box. New things go into (2). When something is mature, and is of general interest, it needs to go into (1).
Strongly agree.I only use Git, so vote for that, but Mercurial/Bzr are generally considered as good, just take your pick.
Personally I strongly dislike SF because it's slow and clunky, rubbish mailing lists and forums... It's the grandaddy though...
I strongly like github for code because it's just so simple to "bookmark" and watch stuff you like (use it alongside a proper website or sourceforge for the project site). Also whilst I have a git infrastructure here, I love the "fork" button on github which gives you a simple hub where you can hack on other people's projects and easily push back changes if appropriate. In contrast on other projects where people run their own git infrastructure I can at least hack my own changes, but I'm afraid to say I rarely bother to contribute code back again because of the difficulty of putting my changes up where people can see them... (Sorry, but if it's more than trivially easy to contribute then people won't do it...)
So github wins by making it super easy to contribute code changes back to a project... Even if the upstream project doesn't accept the changes then it's massively useful for other people to contribute and hack on that code. A case in point is the ActiveMerchant credit card library where the upstream is oddly declining to accept contributions to use 3D Secure which is required in the UK - however, there is a quality code contribution adding this feature and then a half dozen forks from that which polish those changes in various directions - probably eventually one of the forks of the forks will be accepted upstream, but in the meantime it's really easy to have a go at wining the chase from that "half done" starting point.
Coming back to someone's previous comment - git also makes it fairly straightforward to track changes to *several* forks at once, *and* integrate changes from the upstream master. This is unbelievably cool if you need it!
Cheers Ed W