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.
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