I've been reading some of the comments on Josh Berkus' article on LWN about the transition to git. It's a subscription site, so unless you're a member you won't be able to view it until Oct 21st.
A couple of things struck me while I was reading.
First several people commented about how the buildfarm could just do this or that, that migrating was no big deal. Apparently few or none of them had actually bothered to look at the buildfarm client code to see what it does. They seem to have just thought "Well, it uses git to fetch the code. How hard can that be?" But, of course, it's a good deal more complex than that. I'm not going to go into all the details here - you can see them if you're interested at pgFoundry. What struck me though was that some people who commented on this aspect seemed to have neglected to burden themselves with this knowledge.
The other thing that struck me was people's willingness to prescribe a workflow that the PostgreSQL project should be using. Now, not everyone is as dogmatic as these people. The leading text on git describes several different sorts of workflows. I'm usually pretty wary of other people telling us how we should operate. Work practice is not a case of "one size fits all." I also think that some of these commenters can't see the wood for the trees. As far as I'm concerned, the killer feature of git (or any distributed SCM) is the ability of developers to create and maintain private local branches. How stuff gets merged from one repository to another is a secondary consideration. Saying that if we don't do it the way they approve of we might as well be back on CVS, or using Subversion, is just really really silly.
No doubt as we gain experience with git we'll adjust how we do things. How much remains to be seen. I think we'll see more and more people making their development repositories publicly available, and we'll probably start to see committers, reviewers and testers wanting to pull directly from those, rather than trying to apply large patches. For example, I have just pushed the branch I'm doing the extensible enum work on to github, and anyone can pull it from there.
A couple of things struck me while I was reading.
First several people commented about how the buildfarm could just do this or that, that migrating was no big deal. Apparently few or none of them had actually bothered to look at the buildfarm client code to see what it does. They seem to have just thought "Well, it uses git to fetch the code. How hard can that be?" But, of course, it's a good deal more complex than that. I'm not going to go into all the details here - you can see them if you're interested at pgFoundry. What struck me though was that some people who commented on this aspect seemed to have neglected to burden themselves with this knowledge.
The other thing that struck me was people's willingness to prescribe a workflow that the PostgreSQL project should be using. Now, not everyone is as dogmatic as these people. The leading text on git describes several different sorts of workflows. I'm usually pretty wary of other people telling us how we should operate. Work practice is not a case of "one size fits all." I also think that some of these commenters can't see the wood for the trees. As far as I'm concerned, the killer feature of git (or any distributed SCM) is the ability of developers to create and maintain private local branches. How stuff gets merged from one repository to another is a secondary consideration. Saying that if we don't do it the way they approve of we might as well be back on CVS, or using Subversion, is just really really silly.
No doubt as we gain experience with git we'll adjust how we do things. How much remains to be seen. I think we'll see more and more people making their development repositories publicly available, and we'll probably start to see committers, reviewers and testers wanting to pull directly from those, rather than trying to apply large patches. For example, I have just pushed the branch I'm doing the extensible enum work on to github, and anyone can pull it from there.