joe at eireneh.com
Sun Mar 25 12:28:37 MST 2012
On 17/03/2012 20:52, DM Smith wrote:
> Matěj (and others):
> Well, I've read every thing you provided. Reading the "book" took several days and I had to re-read a few because they didn't make sense until I read the book.
> Joe and Peter thanks for your input. That encouraged me to look at it sooner rather than later.
> In order to go to git, I think there are a few things that need to be worked out.
> 1) When? Should it be after the next release? Or can it be done now without impacting the release (other than a little bit of time)?
> 2) How? I agree with you that 3rd party code and jar artifacts shouldn't be in the repository. It's not that big a deal with SVN as one only gets the top level, so each is included only once in the checkout, but with git every upgrade is included in the checkout. The question I have is how that should be done? How do we find them in svn? Where do we put what is currently needed? (I'm thinking the maven repository that we've stood-up on CrossWire, if it is not in maven central.)
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
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?
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
> 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.
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.
> 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.
Perhaps it would help if someone did a quick intended-for-delete
conversion to see what we came up with? Would you like help?
More information about the jsword-devel