[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Axiom-developer] Re: Close Issues -> Close Fricas Issues
From: |
Martin Rubey |
Subject: |
[Axiom-developer] Re: Close Issues -> Close Fricas Issues |
Date: |
28 Dec 2007 14:55:43 +0100 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 |
Dear Bill, *
> I am not against revising the status categories so they are more specific and
> better organized but I do think it is essential that we treat all
> versions/forks of Axiom on an equal footing on the NewSynthesis Axiom
> Wiki. Doing things the way you suggest does not seem sufficiently equitable
> to me.
As some of you may have noticed, I spent some effort in getting IssueTracker up
to date, at least with respect to FriCAS. I would now like to further pursue
this by revising the possible statuses and categories.
My intention is to simplify as much as possible the classification process for
bug submitters. For developers (for example, myself) it is also important to
have well classified issues, because I am sometimes in bug squashing mood, and
then I go through the bugs and look which one I think I'm able to close given
the amount of time I can spend. Currently it takes already half an hour to
reclassify ill-classified bugs...
Thus, I ask you to comment. I'll wait a week or so (unless I get only
encouraging comments), if I do not get any comments until then, I'll just go
ahead. Meanwhile I'll only reclassify.
Happy new year,
Martin
Here comes the proposal:
statuses:
I suggest to reduce the possible statuses to:
open
closed
fix proposed
rejected
duplicate
not reproducible
need more info
I.e., the statuses
assigned [1], revised [0], postponed [1], planned [1], pending [6], testing [1]
should be deleted. The issues currently listed with this status (in square
brackets the number of such issues) can all be easily reclassified.
categories:
I suggest to reduce/change the possible categories to:
Axiom Compiler (rename to SPAD compiler)
Axiom Library
Axiom Interpreter
Axiom Documentation
Axiom User Interface
Axiom-Aldor Interaction
MathAction
lisp system
I'm not so sure what to do with:
Axiom on Windows
Axiom on Linux
Axiom on MacOSX
building Axiom from source [23]
There are indeed problems particular to MS Windows or Linux or MacOSX, but
often these are related to the build process. On the other hand, build
troubles are often common to all platforms... The problem I have is that
sometimes submitters put bugs into Axiom on Windows even though it's really a
problem with the Algebra code. I guess, the best thing is to keep it for now.
Doyen CD
this could possibly be merged with Axiom User Interface
All other categories should be deleted. Reasons:
Aldor Library Compiler [6]
Aldor Standalone Compiler [2]
Aldor has its own bug-tracking system, and as long as Aldor is non-free, we
cannot merge the bug databases.
Axiom Mathematics [28]
most of the issues in this category should be moved to Axiom Library, some to
the Axiom Interpreter. I guess the original intention was to provide a place
to discuss problems of design, rather than programming (like, for example,
semantics of 'Fraction Fraction R' or 'Complex PF 5'). I propose to delete
this category, since it seems to confuse many users.
general [4]
Quite superfluous. Such issues can be sent to the mailing list, with a higher
chance of being resolved.
Axiom Programming [1]
Axiom Foundation [0]
Donations [0]
Bounties [0]
New feature request [3]
easily reclassified.
Comments welcome,
Martin
[Axiom-developer] Re: Close Issues -> Close Fricas Issues, Martin Rubey, 2007/12/14