[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Axiom-developer] Re: Close Issues -> Close Fricas Issues

From: Bill Page
Subject: [Axiom-developer] Re: Close Issues -> Close Fricas Issues
Date: Fri, 28 Dec 2007 11:47:30 -0500

On 28 Dec 2007 14:55:43 +0100, Martin Rubey wrote:
> 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.

Thanks, Martin. I really appreciate your work on this!

> 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...

I agree.

> 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.

If you need any technical help changing the list of categories just
let me know. (You will find the list of categories under the
properties tab in the mathaction folder in the Zope management

> Meanwhile I'll only reclassify.


> 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.

I agree.

> 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

These also would seem to interact with the new "Axiom Version" field.
Right now that field also affects work version of Axiom is run to
create the output on the page (if any). Maybe that was not a good idea
since I think it would be convenient to be able to enter "Windows and
MacOSX" here but right now there is no way to run these versions on
the mathaction (sage.math) server which is a linux system. In
principle this should be possible through a remote or virtual machine
but it might be a bit challenging.

>     building Axiom from source [23]

I believe that we should keep this one. It's use seems clear to me.

> 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 agree that as "categories" they do not make much sense.

> I guess, the best thing is to keep it for now.

I am not sure. But Having two fields in the issue report such as 1)
"affects what Axiom Version ..." and 2) "execute examples using Axiom
Version ..." seems confusing to me. Any other ideas?

>     Doyen CD
> this could possibly be merged with Axiom User Interface

I think it should remain separate.

> 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.

I do not see th license status as a problem with respect to reporting
bugs. Having duplicate bug reporting systems is a problem that we have
to live with. As a library compiler for Axiom I think it is necessary
that we categorize Axiom-related Aldor bugs here.

>     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.

You are right. There are other pages on the wiki where more general
issues like this can be discussed.

>     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]

I think these can be deleted.

>     New feature request [3]
> easily reclassified.

I can imagine some good reasons why we should continue to classify
some reports as "feature requests".

Bill Page.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]