J Aaron Farr wrote:
git could be an issue.
Can you explain what the issue is with Git? We have at least seven contributors (three at Facebook, four external) using git-svn right now, and I know that at least a few of us would really like to use native Git as the main repository for Thrift. Paul Querna mentioned on the Thrift list that Apache likes things to happen "in the open", but he said that others could explain it better.
If the concern is that key developers would maintain their own repositories and exchange patches in private emails, I can assure you that this is not what we have in mind. Perhaps it would help if I explained the sort of repository I am picturing. (I am locally testing some hooks to implement this, so hopefully we can launch it in a trial mode as soon as I can get a machine.) There would be once central repository that would track the trunk. In addition, every committer would be able to post their own branches to the repository. The preferred workflow would be for a committer to post a patch to a branch in the repo, then send out an email to the list like "hey guys, my patch for project space-age is on branch priv/dreiss/space-age. Do you think this is ready to be merged into master?" Then anyone could go to gitweb to look at the patch, pull the patch into their repo and hack on it, or download a tarball and test it out. I think this is much less error prone than having to manually apply a patch sent over an email. I think it even has the potential to be more open than Subversion. If we encourage developers to continuously push their experimental work to the repository in branches, everyone could "follow along" and contribute. I think this is a much better situation than the current case with Subversion where local changes that aren't ready to be merged into the main repository yet stay on developers' private machines.
I also have a set of scripts to allow non-committers to submit changes directly to the repository, tag the submissions, and email a list of committers. There are two benefits of this. The first is that it is a far less error prone way for patches to be submitted and applied. The second is that non-committers would submit patches for consideration in almost the exact same way as committers. This way, new committers wouldn't have to change their workflows at all, and we wouldn't have to worry about them making "newbie" mistakes, because they would just continue to work in the same way that led us to believe they would be responsible committers.
Well, this email is getting a bit long, so I'll cut myself off here. Let me say in closing, though, that I don't want this issue to hold up the vote on Thrift. I think that everyone involved with the project thinks that Apache is the best place for it, and if the PMC says we have to use Subversion, we will. But please consider Git. Thank you.
--David --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
