> No argument from me. The only thing I would be concerned about is
> making sure that the tooling supports it. The project needs continuous
> integration and a repository inspector, and ideally an issue tracker
> linked into both of these. I have used the Atlassian tool set to do
> this in the past which works well, but I don't think they are
> supporting git yet… yep just checked and they still aren't though they
> plan to.
Although I see your point, I think we can find suitable substitutes that
(while not as tightly integrated as the Atlassian suite) will give us what
we need and support git natively.
This might warrant some further investigation. If it turns out that git is
too widely unsupported, we may need to stay with subversion.
It makes sense to me to move this project to Codehaus or even Apache.
> Although Apache is quite strict on the projects they host so Codehaus
> might be a better choice. They have all the tools and admin interfaces
> to manage them, not to mention free bandwidth. It also adds a certain
> aspect of credibility to the project by having it hosted by a well
> known hoster of open source projects. Plus, it allows the developers
> to focus on developing rather than installing and configuring software.
We'd have to look into the copyright issues surrounding the ownership of the
code. Apache for one requires that the code be owned by the foundation.
Not sure what Codehaus' barrier to entry is like, but on first inspection
they seem to have the Atlassian suite set up, so it's worth considering what
we want to do for SCM before we decide where to host the project long term.
I am not a hardcore git user so I may not have seen the light yet, but
> I would rather stick with svn because of the support for it from
> FishEye and Bamboo for the time being. Individual developers can
> always use git+svn locally to get _some_ of the features.
git+svn would be an option if we're stuck and can't find the necessary
tools, but I think a move to git would be good for the project as a whole.
Git's branching and merging features (among others) are second to none in my
experience; and there are a great deal of features which will benefit a
project under distributed development, as ESOE is and will undoubtedly
continue to be.
Keen to hear more thoughts on this.
Shaun