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 involvement.
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 <[email protected]> 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 http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
