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

[josef.pktd at gmail.com]

On Mon, Feb 23, 2009 at 11:44 AM, David Cournapeau
<david at ar.media.kyoto-u.ac.jp> wrote:

>
> I agree that tools cannot solve the problem of lack of test. But to give
> you a scenario: I had a couple of hours to spend on triaging bugs on
> numpy for 1.3 release last WE. I have done almost nothing: I can't
> easily get tickets with attached patches, I can't control the bug
> tracker from the command line (I can't say: give me all the tickets
> since 1.2 with attached patches, give me all tickets on numpy.core since
> 1.2, etc...). I find the whole workflow extremely frustrating personally.
>

This seems to me to be a problem with the (older) trac ticketing.
Queries for attachment, I found, work ok, but I didn't find a query
for tickets with recent comments. Going through the stats review
tickets to see which have any relevant information is really slow, and
I still never went through all of them to see if someone added a
comment or not.   Has this improved with the new version of trac,
scipy trac is 0.10.2 and current trac is 0.11.3?

But I don't see how changing the revision control system helps with this.

I installed msysgit following the links provided and the git gui looks
ok, although the file browser is missing the basic file information
(revision numbers, dates, added to repository or not). I don't like
the bash shell because I don't know the keys for basic things (or I
have to look them up), but that's only a smaller problem.

The question is whether the revision control should be easier for
developer or easier for users to create patches, and that might not be
the same system.

Also, at least with bazaar and bzrsvn and, I guess, git-svn, I still
don't see what the (major) disadvantage for branching is of using a
mirror of the central svn repository in a decentralized version
control.

(However, I usually just work with only short lived branches to try
out fixes and new code, or do selective merging manually. Personally,
my second incentive for keeping essentially only one main branch (svn)
in my own code is, that I am not very well organized with branches,
and having 10 to 15 versions/branches of a package on my hard drive
ends up just wasting space and time. Also, I like the svn integration
in eclipse.)

Josef

I wrote this quite some time ago. But, being one of the (few?) pure
Windows (and GUI) users, I'm still in favor of the current, familiar
setup, with svn and trac. Code review tools are also available for svn
(and in python, see google code), however, code review won't change
much if the man power isn't there.