2010/5/27 Stéfan van der Walt <stefan@sun.ac.za>
On 26 May 2010 23:27, Charles R Harris <charlesr.harris@gmail.com> wrote:
Exactly. I had a private bet with myself that that would be the case. See, it isn't so much different after all. The tools change, but the problems and solutions remain much the same.
In this case, I believe the tool may be part of the solution. With limited manpower at our disposal, having a somewhat painful process certainly doesn't help.
It should help. A commitment to doing reviews is probably more important here than submitting for review. It's less fun than development and takes a certain commitment. Of course, there are probably some perverts out there who find it enjoyable. I hope we find some.
- Working with patches is unreliable (check out all the patches in Trac that don't apply cleanly and how much effort it will be to fix them). Distributed revision control provides a much better structure within which to manage patches.
Two year old patches are always going to be a problem. The real fix here is not to let things languish.
- Merging in SVN is horrible and will never encourage branches. Without branches, trunk becomes turbulent easily.
True. Although there would need to be more activity to get to true turbulence.
- We currently don't have any code review in place. This isn't SVN's fault, but tools such as GitHub's compare view (http://github.com/blog/612-introducing-github-compare-view) look really promising
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. Chuck