[SciPy-dev] The future of SciPy and its development infrastructure

[Pauli Virtanen]

Mon, 23 Feb 2009 10:29:25 -0800, Matthew Brett wrote:
> In the spirit of the 30 second reader, I split your email into your two
> parts.
> 
> 1. Change to a distributed revision control system, encouraging more
> open collaboration.
> 2. Determine guidelines for code acceptance, in terms of unit tests,
> documentation and peer review.
> 
> In that order:
> 
[clip]
> 1) The distributed vs SVN issue is one that generates a lot of heat.
> Perhaps we could back off that one for now?  We've been using bzr for a
> while.  It's been a mixture of confusing and liberating.  Like writing
> tests first, it's very difficult to explain why DVCS is important.  It
> does require a lot of discipline for it not to get out of hand.

Using a DVCS makes the life of a contributor easier:

- You can track upstream changes.

- It in general feels much more secure to have your upcoming contribution
  in a version control system from day 1 so that you can't lose anything.

  In practice, I've found myself using Git in Numpy/Scipy development,
  even though I have SVN commit access.

- You have a single standard way to publish your current version of
  the proposed change (ie. push to a branch in a git repo somewhere).

  The current practice: multiple versions of patches on the mailing list
  or attached in Trac.

Granted, the two first you get with git-svn. But I assume many people 
don't know that such tools exist.


Having the official repo in DCVS may also help the gatekeeper:

- There are code review tools for DVCSes. Eg., you can comment a patch
  line-by-line in Github.

  Compare this to unpacking a .tar.gz sent to mailing list, and commenting
  on it.

- You can track the contributor's changes easily.

  No need guessing which version the patch was based on against, or which
  version of the patch is the latest.

- You can merge the contributor's changes in easily; a DVCS usually does
  better job resolving conflicts than applying a patch.

> 2) Yes.  Please.  That would really help.  How do we think we should
> best get there?  If we don't switch to DVCS immediately?

The problem with patch review is mainly, I think, lack of manpower and 
dedicated maintainers for subcomponents.

Also, it seems that it's not very clear to contributors how to submit 
their code, and what is required.

A DVCS could formalise and streamline part of the above. But it doesn't 
solve manpower and lack-of-responsibility issues.

-- 
Pauli Virtanen