If it's going to be git then the issue tracker needs to change. Take a
look at lighthouse. I am not a huge fan but it's integration with
github is tight. I don't know if there is a solution for lighthouse
> On 01/03/2009, at 5:24 PM, Shaun Mangelsdorf wrote:
>> 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.
> Hudson is a good example here. Where possible I'd like to stick to
> other open source solutions to support the project. We've been using
> Hudson in the past with great success and flexibility.
>> This might warrant some further investigation. If it turns out that
>> git is too widely unsupported, we may need to stay with subversion.
> Hudson at least seems to have pretty decent GIT support
> http://wiki.hudson-ci.org/display/HUDSON/Git+Plugin
>> 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've had at length discussions with the Apache folks before we got
> semi close but there are some major blockers that we couldn't get
> around, particularly in the C++ side.
> I for one am actually happier with the project standing on its own,
> the less we need to deal with other groups political processes the
> more time we spend on the many various facets that make up ESOE.
>> 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.
> I'd really rather one or the other and not be trying to support some
> hybrid. Common sense would have to tell you that eventually that kind
> of arrangement will come unstuck and cause headaches.
>> 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.
> Totally agree.
> Bradley
>> Keen to hear more thoughts on this.
>> Shaun
> Bradley Beddoes
> Lead Software Architect
> Intient Pty Ltd
> http://www.intient.com
> Twitter: @bradleybeddoes
|
