On 27 May 2010 04:43, Charles R Harris <charlesr.harris@gmail.com> wrote:
Maybe most importantly, distributed revision control places any possible contributor on equal footing with those with commit access; this is one important step in making contributors feel valued.
Well, not quite. They can't commit to the main repository. I think the main thing is to be responsive: fast review, quick commit. And quick to offer commit rights to anyone who sends in more that a couple of decent patches. Maybe we should take a vow to review one patch a week.
Okay. Suppose we wanted to replicate the current permissions arrangement as closely as possible with git. It seems to me it would look something like this: * Set up a git repository somewhere on scipy.org. * Give everyone who currently has permission to commit to SVN permission to write to this repository. * git submissions would become possible: a user would make some changes but instead of posting a patch would link to a particular git state. The changes could be reviewed and incorporated like a patch, but with easier merging and better history. If the changes became out of date the user could easily merge from the central repository and resolve the conflict themselves. * Patch submissions would be reviewed as now and committed to git by one of the people who do this now. Alternatively they could be integrated to the mainline by someone without write access and published as a git change, to be incorporated (easily) as above by someone with write access. * if review and inclusion were slow it would nevertheless be easy for users to pull from each other and build on each other's changes without making the eventual merge a nightmare. So, no major change to who controls what. The nipy/ipython model takes this a step further, reasoning that git makes branching and merging so easy there's no need for such a large group of people with write access to the central repository, but if that doesn't work for numpy/scipy we don't need to do it. And we can change in either direction at any time with no major changes to infrastructure or workflow. To get back to the original point of the thread: nobody has yet objected to git, and all we have are some debates about the ultimate workflow that don't make much difference to whether or how git should be adopted. Is this a fair description? Anne