Much ado about scripting, Linux & Eclipse: card subject to change

2009-05-04

Git 'Er Done

The discussions in bug 257706: Host a git repository on Eclipse Foundation servers, support git as the repository of Eclipse projects rages on, wind blowing in both directions.

Let's look at the objections to Git @ Eclipse:

Implementing a common build infrastructure would also be complicated by additional code repositories as well.

Not true; the Athena system already supports CVS and SVN, plus a "build from local sources" mode which works w/ a cvs/svn tree dump, a workspace w/ checked out projects, or (TBD, we haven't tested this yet) with a git repo. And we have an open bug to make repo tree structure irrelevant to the local checkout mode. Party on. There is even a Git plugin for Hudson so you can use Hudson to watch your repo for changes, like it does with CVS and SVN.

Can't use unapproved or non-EPL code at Eclipse.org

Not true; from discussions w/ legal@eclipse.org, I've been told at least twice that as long as you're not SHIPPING code that falls under a non-EPL or non-approved-CQ you're entirely fine to USE that code as server-based infrastructure. Rock on.

Cannot include tooling in a release train or host its project at Eclipse.org

Not true; since eGit is EPL and jGit is BSD, I don't see a problem with distributing the tooling that would connect to a Git repo hosted at Eclipse.org. We worked around the license woes for SVN tooling support. We can do it again. (Of course IANAL, TINLA.)

Conclusion:

No legal concerns with use of Git as hosted server infrastructure. Dash Athena (Common Builder) will support Git. Tooling is safe for inclusion in release trains (either fully like CVS is or partially like SVN is).

Only remaining issue is therefore to get it installed and allocate resources to support/manage it. With all the erosion going on lately, this need should not be trivialized.


Before the thaw this spring, this tree was on top of the bluff. With nothing to support it, it was dropped like an unchampioned feature request.

However, in the spirit of open source, several people on the above bug have offered to help w/ setup, testing, support, etc. So the burden here will be shared, like many things at Eclipse (eg., Babel, Hudson). Erosion continues, but we can all help to shore up the loss.

As most people prolly already know, Sourceforge supports the whole spectrum of VCS and DVCS options. If we don't want people to host projects there, Eclipse has to at least offer something from the DVCS world to encourage participation here. Keep the barrier to entry high, and people will go elsewhere. Lower the barrier, and people will come here to party instead.

With everyone feeling the economic- and time-pinch these days, can we really afford to discourage contributions at Eclipse simply because, as the silverbacks say, "why, back in my day, we only had CVS, vi, and notepad, and dangit, that was good enough!" ?

After all, the new world is inevitable.

3 comments:

David Carver said...

+1 Nick. I've actually have a need right now to continue working on code, but don't have the permission to setup a branch, and want to continue getting the head bug fixes. Instead of being able to check the code in for the W3C PsychoPath tests into a version control system, I'm stuck creating patches and storing each one in bugzilla until July when things unfreeze again.

With a DVCS I could push all these changes out in July to the master once the freeze date ended, and still continue to have the benefits of version control with my own dvcs. I'm stuck with the limitations of politics and CVS.

AlBlue said...

I don't think that there's confusion about EPL (or non-EPL code) in the bug discussion. Most of the questions are coming from 'why can't we use Hg/Bzr/...' - and it doesn't make sense to ship plugins for a DVCS that requires a non-Eclipse.org originated (GPL) download.

AFAIK Git is in a group of one, in that JGit is BSD. Everything else would require linking against GPL.

It's somewhat irrelevant what's used on the server-side; that's not code that's shipped by Eclipse.

nickb said...

@Dave: Use the Forge, Luke. Use the Forge.

@Al: I'm sure (wishful thinking, perhaps?) if we had one DVCS solution the "My DVCS is better than your DVCS" naysayers would at least concede that *having* Git is better than *not having* Git, Bzr, or Mercurial/Hg.

But really, for me, it's not a question of licensing. I can work around the nightmare that is SVN installation. I just want tooling that works, and from what I've heard, that's eGit, not BzrEclipse or MercurialEclipse.