In fact, it is a much less critical decision which host to chose than it may seem. After creating the repository, the main developers don't have to visit the web pages of the host any more. The only thing they have to do is to push the changes to all the git hosts geany will use (it could be sourceforge, github and gitorious in parallel - it will be up to the contributors which one they'll chose [probably github or gitorious because these can host their own clones]).
Can they create a local clone of a repo on some other server, without having to create a project? That would be good!!
This can even be
automated if the push is made on your own server and then propagated by some script to all the mirrors. The web pages of the host will be visited only by the contributors who want to create their own clone (and from this point they can also forget about the web interface). There are features like "merge request" at gitorious that notify the maintainter about the merge from a contributor, but this can be disabled so the only way the contributor will ask for merging his work will be through the mailing list and publishing url of his repository (wherever it is located).
Thats closer to the current way of working and is better IMO for pathes that are more than one-liners, some explanation of what the change is and what it does is useful.
Git is a distributed VCS - it doesn't matter where the user pulls from
- whether it's some host like gitorious, the official repository, or a
local clone on your machine - the mirrors should just be kept up to date. And for instance if github is not officially supported and there is some github lover, nobody prevents him from pulling from the official repository and pushing to a github clone so he keeps it more or less up to date (I did the same with the current geany gitorious repository [I just don't keep it up to date, but I could of course] - there will be no difference for people if they pull from there or your official git mirror). And if you dislike one host and want to move to another one, you'll just move the repository there - all the user's local clones will be still valid, they'll just have to start pulling from a different url.
Which confuses everyone, so it shouldn't happen too often.
So the question should rather be WHETHER to move and not WHERE to move
- the latter is much less important at this point. The only thing I'd
like to see is that one of the repositories makes it possible to create personal clones for external developers.
Agree
Cheers Lex
Cheers,
Jiri _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel