[SciPy-dev] The future of SciPy and its development infrastructure
Charles R Harris
Mon Feb 23 15:06:24 CST 2009
On Mon, Feb 23, 2009 at 1:00 PM, <email@example.com> wrote:
> On Mon, Feb 23, 2009 at 11:44 AM, David Cournapeau
> <firstname.lastname@example.org> 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.
Bash on windows is ugly anyways ;)
> 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
I think git-svn takes care of most of the branching problem on a local
basis. Where it fall down, IMHO, is in testing a branch on the builtbots and
sharing a branch among two or three people.
> (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.)
I tend to agree that changing the VCS shouldn't be the first priority. It
sounds like tracking the tickets and svn changes relevant to particular
tagged releases might be where the effort should go.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Scipy-dev