tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Howard Lewis Ship <hls...@gmail.com>
Subject Re: Status of Git at Apache
Date Wed, 02 Dec 2009 21:21:57 GMT
There's definitely a bit of conflict going on here. On the one hand,
Apache's central message is all about community, but at the same time
(for the sake of the legal umbrella and CLA's) we are embracing a tool
(SVN) specifically to act as a choke point preventing community

As a side note, I believe Ted Leung had a story at ApacheCon about the
loss of several months of Subversion commits and how, fortunately, he
had an archive of the commit mails and the knowledge to reapply all
the changes from those commit mails. In the world of Git, you could
follow that route, or recover official changes from any repository of
any committer or other user.

We've seen a side effect of Git's "code immortality" with Why the
Lucky Stiff, who deleted his online presence (including many GitHub
projects) a few months ago, but new GitHub projects were created from
other user's forks, losing none of his history.

The point is, it chagrins me to use a lesser tool, especially since
outside of one area, it does not address (from a technical
perspective) the goals of the Apache community.

On Wed, Dec 2, 2009 at 1:02 PM, Doug Cutting <cutting@apache.org> wrote:
> Howard Lewis Ship wrote:
>> So what I'm hearing is that as long as external code is delivered via
>> a JIRA patch, and the JIRA issue is referenced in the commit, then
>> there's no difference between Git and SVN from a legal stand point.
> It's not black and white.  The Jira signoff and even a CLA aren't strictly
> required, since the license itself says that its terms apply to anything
> that's intentionally submitted.  However we like to have good documentation
> of that intent.  Jira's checkbox provides this.  The ICLA provides this.
> A concern with Git is that a committer might push and pull changes from
> others, work on them, then commit the collaboratively produced code, with no
> clear point to document the intent of those others.
> Of concern with this pattern is, as mentioned, the decreased documentation
> of intent.  But also of concern is the decreased visibility of these
> interactions to the community.  With subversion+Jira, a project has a single
> patch repository and a single source code repository that all interactions
> go through, so that any member of the community can monitor progress on
> every issue in a single place.  But, when folks are collaborating in a
> distributed manner there's no longer a single point to monitor: to track the
> project one must monitor the individual Git repos of each developer.
> To use an analogy, it's a bit like C++'s operator overloading, which I view
> as a bad idea (pretend you agree with me, for the sake of this discussion).
>  In C++ projects you need to enforce a coding guideline against using this
> language feature.  In Java projects you have no such need, since Java simply
> doesn't have operator overloading.  Similarly, Subversion doesn't easily
> support distributed development, while Git does.  The ASF wishes to
> discourage distributed development and is thus wary of embracing Git as a
> primary tool.
> Finally, there's the infra issue: subversion is our highest priority
> service, the one infra works hardest to keep running reliably without data
> loss.  Properly supporting another source code management system would not
> be free and would spread our infrastructure resources even more thinly and
> can thus not be considered lightly.
> Doug

Howard M. Lewis Ship

Creator of Apache Tapestry

The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!

(971) 678-5210

To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org

View raw message