Where to start with this blog post? It appears that the author has seen a couple of private emails and thinks he knows all about the internal workings of the Apache Foundation. He is wrong on so many counts.
His entire dislike of the Apache Foundation appears to be predicated on the fact that the organisation did not force every project to move to this blogger's favourite version control tool. Making a change as large as this requires many different things, but in particular:
1. Community change. How committers interact with each other when there are lots of forks is quite different to the current situation. That suits some projects and not others. Not every project at Apache will benefit. Some will. All who change will need to think long and hard about release processes, merging strategies and much more. Git encourages the idea that every commit or fork is completely equal to every other fork or commit. The Apache Foundation is built on the concept of meritocracy: commit rights are given in response to demonstrated skill. This is not an intractible problem with git, but new challenges need to be solved.
2. Legal change. Right now there is a simple process for signing off intellectual property for contributions which were merged from external contributors (who have not signed a release). That changes with git and becomes more complex. There are solutions, but they require careful planning.
3. Infrastructure. Hosting a large git repository with the level of downtime acceptable to Apache isn't something you do quickly. That needs planning and maintenance.
4. Toolsets. Lots of things in Apache are tied into subversion. From mailing list commit hooks to build servers and much more. Changing those things takes work.
5. Splitting the community. Right now the entire organisation's intellectual property is held in a single repository. Everyone knows where everything is to be found. Changing this simplicity requires a very good reason.
So what do we have now? A blogger who (it appears) doesn't actually contribute code to any Apache project. Telling other people how to run their organisation (which is wildly successful). And that they should change to this blogger's favourite new tool (they should have done it in 2008!) or face irrelevance.
If Apache moved every project to github tomorrow would that satisfy this blogger? More importantly, would that have caused this guy to commit high quality code toward one of the Apache projects? Or is he just blowing a lot of hot air about something he knows little?
And what brought on this great complaint? That the Apache Foundation is currently underway with trials for one project to see how git would succeed for their workflow. And to then evaluate its suitability for other projects across Apache.
Apache is not Github. That is, Apache is much more than a website, a couple of tools and a repository of code of random quality.
Disclaimer: I am an Apache member, but not speaking on behalf of Apache
> 2. Legal change. Right now there is a simple process for signing off intellectual property for contributions which were merged from external contributors (who have not signed a release). That changes with git and becomes more complex. There are solutions, but they require careful planning.
I'm curious as to how exactly you feel git impacts on Legal processes versus the use of svn. I'd expect that the choice of tools and the legal issues surrounded merges made by those tools should be completely orthogonal.
With an svn workflow the committer sends each patch in a single authenticated request directly to the Apache svn server. With every commit they are saying "this code is appropriately licensed, even though the code may have come from other committers. The history of that code is completely obscured."
With a git workflow, the push (which is authenticated against a committer who has signed the appropriate license agreement) could contain multiple commits from other sources. This is particularly the case if it includes code from a pull request. The Apache git tree will then have commits with publically visible attribution to people who are not Apache committers and may not have signed the appropriate license agreements.
I am not saying this is a deal breaker, but it does require some thought. We don't want some contributor to come back three years later and say "that contribution from me: it was only released under the GPL". We need clear guidelines around that original pull request and how copyright/patent signoff happens. Right now, third party contributions go through a Jira patch process which includes a copyright/assignment tick box.
Doesn't simply requiring that all pull requests be squashed down to a single clean commit from a developer known to have signed the license agreements give you back the exact scenario you have under SVN?
Anecdotally, a lot of projects I've been involved with have required that pull requests be squashed to avoid polluting the "main" repo with irrelevant/undesired third-party history.
The ASF is missing the boat here. It is like ... the 21st century? And core people of the Apache are not only thinking “SVN should be enough for everyone” but also make it exceptionally hard for projects to use the rigth tool for their job.
My bet is still on Git being shot down due to some random made-up “quality concerns” in the end.
ASF went from a helpful free software organization to a software graveyard: Ant, Maven, Subversion, Commons, OpenOffice ...
Are you just trolling or trying to make some point? What part of "Apache is currently evaluating git" makes you feel that git is being shot down?
Git is just a tool. In five years there will be another tool that everyone cannot live without. And people like you will be telling Apache that they are dinosaurs because they have not moved to that. Right now some very dedicated and skilled people are donating their free time to running the Apache organisation and evaluating the feasibility of making changes. And you accuse them of lying about quality concerns (which no one has even raised). Meanwhile, your assistance to the advancement of open source is what exactly?
His entire dislike of the Apache Foundation appears to be predicated on the fact that the organisation did not force every project to move to this blogger's favourite version control tool. Making a change as large as this requires many different things, but in particular:
1. Community change. How committers interact with each other when there are lots of forks is quite different to the current situation. That suits some projects and not others. Not every project at Apache will benefit. Some will. All who change will need to think long and hard about release processes, merging strategies and much more. Git encourages the idea that every commit or fork is completely equal to every other fork or commit. The Apache Foundation is built on the concept of meritocracy: commit rights are given in response to demonstrated skill. This is not an intractible problem with git, but new challenges need to be solved.
2. Legal change. Right now there is a simple process for signing off intellectual property for contributions which were merged from external contributors (who have not signed a release). That changes with git and becomes more complex. There are solutions, but they require careful planning.
3. Infrastructure. Hosting a large git repository with the level of downtime acceptable to Apache isn't something you do quickly. That needs planning and maintenance.
4. Toolsets. Lots of things in Apache are tied into subversion. From mailing list commit hooks to build servers and much more. Changing those things takes work.
5. Splitting the community. Right now the entire organisation's intellectual property is held in a single repository. Everyone knows where everything is to be found. Changing this simplicity requires a very good reason.
So what do we have now? A blogger who (it appears) doesn't actually contribute code to any Apache project. Telling other people how to run their organisation (which is wildly successful). And that they should change to this blogger's favourite new tool (they should have done it in 2008!) or face irrelevance.
If Apache moved every project to github tomorrow would that satisfy this blogger? More importantly, would that have caused this guy to commit high quality code toward one of the Apache projects? Or is he just blowing a lot of hot air about something he knows little?
And what brought on this great complaint? That the Apache Foundation is currently underway with trials for one project to see how git would succeed for their workflow. And to then evaluate its suitability for other projects across Apache.
Apache is not Github. That is, Apache is much more than a website, a couple of tools and a repository of code of random quality.
Disclaimer: I am an Apache member, but not speaking on behalf of Apache