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

[Ravi]

On Thursday 26 February 2009 10:40:24 jason-sage@creativetrax.com wrote:
> > 2) While I understand the desire to increase the quality of commits to  
> > scipy by putting in a more formal process, like making sure code is  
> > reviewed, tests are present, and documentation is provided, I too,  
> > like Travis, worry that this may inhibit many useful contributions.  
> > Rather than act as a barrier, why not just have some sort of "seal of  
> > approval" for things that have gone through that process.
>
> Lots of projects have -stable and -dev branches.

Please, NO! This does not scale. This is the process used in Boost and makes 
the release process a nightmare. Boost svn commit access is not easily gifted; 
virtually every library in Boost goes through extensive review and its authors 
are generally way-above-average programmers. In spite of all the preceding, 
getting a Boost release out is a superhuman effort:
  - tracking commits between branches is a full-time job
  - the -dev branch becomes "the wild west" very easily (slippery slope)
  - if no feature freeze, bug fixes get done even slower

What you want, in my humble opinion, is what the KDE people call "always 
summer in the trunk". There really is only one scalable way to manage this: a 
DVCS. Instead of using trunk as a playground, use the "trunk" in your clone 
("master" in git). So long as your clone is published somewhere (anywhere on 
the web, for instance), any authorized committer into the main repository can 
pull it. There is *exactly* one more step compared to using svn trunk, viz., 
sending a mail out to the mailing list indicating the change. But then, you 
were going to do that anyway, weren't you?

The best example I can think of is Xorg. See
             http://cgit.freedesktop.org
for a list of everyone's local repositories. (Of course, scipy may choose bzr 
over git, but the point still stands.) Let's say "airlied" just finished 
implementing the feature "drm" for the submodule "radeon r6xx". *His workflow 
is exactly the same as svn*:
  git clone ...                           = svn co / svn up
  # make changes
  git commit -a -m "drm rework finished"  = svn commit
  # send mail to the mailing list
Any interested party in the mailing list reviews the code and pulls it into 
the main repository. Note that "airlied" does no more work with the DVCS than 
with svn; the workflow for "airlied" has not changed other than the command 
substitution above. The above is actually a true story.

Of course, now note that instead of "airlied" (a sanctified committer), it 
could be you and anyone interested (core developer or not) can simply pull 
from you and test it. This lowers the barriers to newbies, in my limited 
experience.

Regards,
Ravi