|
|
ESOE Development |
On 01/03/2009, at 5:24 PM, Shaun Mangelsdorf wrote:
> Although I see your point, I think we can find suitable substitutes
> This might warrant some further investigation. If it turns out that
> It makes sense to me to move this project to Codehaus or even Apache.
> We'd have to look into the copyright issues surrounding the
> Not sure what Codehaus' barrier to entry is like, but on first
I for one am actually happier with the project standing on its own,
> I am not a hardcore git user so I may not have seen the light yet, but
> git+svn would be an option if we're stuck and can't find the
Bradley
> Shaun
http://www.intient.com
> No argument from me. The only thing I would be concerned about is
Hudson is a good example here. Where possible I'd like to stick to
> 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.
> that (while not as tightly integrated as the Atlassian suite) will
> give us what we need and support git natively.
other open source solutions to support the project. We've been using
Hudson in the past with great success and flexibility.
Hudson at least seems to have pretty decent GIT support
> git is too widely unsupported, we may need to stay with subversion.
http://wiki.hudson-ci.org/display/HUDSON/Git+Plugin
I've had at length discussions with the Apache folks before we got
> 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.
> ownership of the code. Apache for one requires that the code be
> owned by the foundation.
> 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.
semi close but there are some major blockers that we couldn't get
around, particularly in the C++ side.
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'd really rather one or the other and not be trying to support some
> 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.
hybrid. Common sense would have to tell you that eventually that kind
of arrangement will come unstuck and cause headaches.
Totally agree.
> 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.
Bradley Beddoes
Lead Software Architect
Intient Pty Ltd
Twitter: @bradleybeddoes