[jsword-devel] Git

[Douglas Campos]

> I think, if we've got maven and it works then that's probably a good answer. The downside of maven is that it's a barrier to entry to a new person. The question is, would we take that risk to save the clone bandwidth.
Do you really think that it's a barrier to entry? I find quite the opposite nowadays...

> An interesting solution might be to have a separate 'binaries' repo where we could, from time to time clear history, whilst I think I understand git enough to know how this would work, we'd need to run some tests to make sure it's ok.
> 
>> 4) Where? What is the best place to serve it? GitHub? Gitorious? Set up a server on CrossWire? If so which server? Gitosis? Gitolite? Other?
At JRuby project we host our canonical server at "jruby.org" machine, and mirror it to github. We accept pull requests, but a committer merges it manually and pushes to the canonical repo, which gets synced to github.

(hope this is not too much confuse)

> 
> I think there are 2 competing issues: control vs. engagement. Github wins hands down from an engagement point of view. It's where the 'cool kids' are. There is a feeling of control that comes with hosting your own server, but I'm really not sure it's worth it.
> Point of reference: Mozilla, which already has a massive investment in continuous integration servers, Mercurial repositories, etc - i.e. it has a full-time team dedicated to looking after a server infrastructure, is using Github for important projects like B2G (essentially a project to make Firefox run on Mobile phones, and able to make calls etc from web-apps.)
> 
>> 3) Who? We have a few users that have write permissions to JSword. Everyone else is read-only. We need this to continue in some form or another.
> 
Indeed, and it's the default model for the majority of github-hosted OSS software.

> If the answer to q4 is hosting-own-server, then permissions might not need to change, but it's probably your call as project-lead if they do.
> If the answer to q4 is Github, then the permissions model is different:
> * If the repo is owned by a person then it's a case of which pull requests the owner accepts, so there is no need for privileged users.
> * If the repo is owned by an organization then you can have a team own a repo. While I think it would be a good idea to have a Crosswire organization, I'm not sure that permissions are needed. Even in huge organizations like Mozilla's the team structure isn't actually *used*, it's there but basically overkill.
It's always nice to have the organization, as it allows space to grow.

Another good point for org is that we can have all the personal forks coming from the "canonical repo", which helps on coordinating stuff.

> 
>> 5) What? How far back do we go? From the beginning, 1.0, 1.6? Over time we've refactored projects in Eclipse several times. It needs to include what is now in the JSword project, which is the merge of jsword-common into jsword. What should be done with the other projects? They can follow later into other repositories, but we will need to have a comparable build system on the CrossWire server that will pull all the code and build it.
> 
> I think my answer would probably be to take the easiest option that saved the most history, and as full history is likely to be the default, we should perhaps take all of it.
> Perhaps the issue is what we do with binary resources. Can we / should we strip them out of the history? I think we'd need to have some better idea of the number involved before we decided that.
I've followed the "strip binaries from history and store 'em somewhere on 100% of the migrations I've did" - no problems so far, and the gains in repo size are massive.

> Perhaps it would help if someone did a quick intended-for-delete conversion to see what we came up with? Would you like help?
Sure! I can do it - we just need to think a little better to avoid wasting work ;)

-- qmx