[Geany-devel] Git switch
techet at xxxxx
Mon Jun 14 13:15:03 UTC 2010
On Mon, Jun 14, 2010 at 09:47, Lex Trotman <elextr at gmail.com> wrote:
> On 14 June 2010 15:41, Thomas Martitz
> <thomas.martitz at student.htw-berlin.de> wrote:
>> Am 14.06.2010 03:58, schrieb Lex Trotman:
>>> I guess we should also consider that no matter how easy we think it
>>> will be there will probably be some disruption during the changeover
>>> so it should be now (immediately after a release) or not until the
>>> next release, which I think is probably better so that the hosting and
>>> workflow issues can be worked through some more. Jiri, hold that
>>> Gitorious project to keep out cyber squatters.
>> 0.19 is just out, why wait for the next release? 0.19 is so recent, waiting
>> for the next release will have no advantage (because we are in the same
>> situation then as today). Can you elaborate that please?
> Hi Thomas,
> Sure, multi part answer.
> 1. Yes you are right, it doesn't have to be *immediately* after a
> release, just before the heavy activity approaching a release.
> 2. What might be better if there is some delay?
> Because I don't think we have got a good handle on host, bug tracker
> etc. The responses were far from unanimous for a switch to Git,
> though no one was heavily against it.
> As far as I can tell Jiri is the only one who has responded who has
> actual experience running a Git project and that is only on Gitoroius.
> So I'd ask:
> * Does anyone else run a Git project, which host and whats the experience?
> * How many people contribute to one, and what hosting service do they
> use and what is the experience, is performance consistent and better
> than Sourceforge SVN, all around the world?
> * And does anyone have experience using any other DVCS and hosting
> service that would make them recommend it, or recommend against it?
> * should the bug tracker be moved? Can it be done without losing anything?
> There are rather a lot of options listed here:
> https://git.wiki.kernel.org/index.php/GitHosting Has anyone used any?
> The important things we need to know about a hosting service are:
> * likely stability, some have gone offline during the GFC, but this is
> hard to judge
> * performance for a good range of users in a good range of locations
> * reliability, low downtime
> * features, hosting clones, bug tracking ?????
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]). 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).
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.
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.
More information about the Devel