On Mar 30, 3:50 pm, David Harvey [EMAIL PROTECTED] wrote:
On Mar 30, 2008, at 6:31 AM, mabshoff wrote:
Hello folks,
there have been a large, nebulous set of rules regarding how things
are done in trac, patch review and merging and the Sage development
process in general. Now I finally took the time to clear those up and
I put a *draft* of the guidelines up at
http://wiki.sagemath.org/TracGuidelines
What I wrote there is obviously not the final version and none of the
rules are written in stone. I would actually like a discussion about
the rules to clear any potential issue where things are either wrong
or unclear. I consider what I wrote down the consensus from having
done releases for the last four months, but even I do make mistakes ;)
I am working on additional sections on workflow and so on. I believe
that eventually the content of that Wiki page should go into the
documentation or that at least a link from the official doc should
point to that wiki page.
On a quick skim-read, I found the Sage Specific paragraph very
confusing. Are you trying to say that if someone makes up their own
version of Sage that ships different versions of packages to the ones
we normally ship, then they are on their own? Or something else?
Short answer: yes. If that person experiences bugs with that version
of Sage they are on their own. They can ask for support and I will do
my best to help them, but that problem doesn't belong in out trac.
Long answer: This is directed toward distribution specific packaging
of Sage when certain components like gmp, pari, GAP that are already
in the distribution are replaced by those distribution specific
versions. In that case I don't think we should trac those issues since
those distributions have their own trackers and I am perfectly content
with fixing bugs in the official version of Sage. Any ticket in the
Sage tracker should be about the official Sage release, i.e. we should
be able to resolve the issue. If your maxima breaks because you are
using gcl 2.6.8 on FUBAR Linux: Not my problem. Our resources
shouldn't be spend on those issues, we have plenty of our own bugs to
fix.
Once you replace components of Sage you get a combinatorial explosion
of configurations and there is no way that we can support it. William
started packaging all those components exactly because of the
combinatorial explosion problem as well as the difficulty of even
compiling all of Sage's components way back when Sage was much
smaller.
So: where to draw the line? I think we should interpret this very
tightly and only support the official release because otherwise there
is no reasonable rule to apply. For example: I swapped clisp for cumcl
on Solaris and it broke a bunch of Maxima tests. I upgrade Maxima from
5.13.0 to 5.14.0 and it broke about five doctests. You see that even
small and innocent looking changes lead to a bunch of problems. I am
not saying that people can't or shouldn't do that, I am just saying I
prefer not to carry a myriad of impossible to resolve bug reports in
out trac. Let the distributions deal with that problem. If Sage were
to release every six to twelve months the issue would probably be
slightly different, but as long as Sage is moving as fast as it
currently is I don't think that using anything but a build from source
or the official binaries will ever get you close to the optimal Sage
experience.
For the record: That rule came specifically from the following
tickets:
#2728: doctest failures for maxima in Debian packaged sage 2.10.4
This is not Sage Specific: It might be due to Debian packaging
an older version of Maxima or alternatively be caused by using gcl
instead of clisp. It is certainly borderline, but I don't think
in this case it is on our end to fix this.
#2730: matplotlib in Debian is too old
This is not Sage Specific: Please file a bug report with Debian
or alternatively package the Sage version of matplotlib.
#2731: GeneratorMatCode doesn't seem to be available in Debian's GAP
This is not Sage Specific: Please file a bug report with Debian
or alternatively package the Sage version of GAP. Alternatively
create
a deb which contains the GAP packages that Sage installs per default.
#2733: PARI in Debian has the mathnf bug
This is not Sage Specific: This is a packaging bug in Debian's
pari.deb and should be filed as a bug report at the Debian bug
tracker.
#2734: SAGE Debian doctest errors whose cause I don't understand
Sorry Tim, this should go to debian-sage or sage-devel. One Issue
Per Ticket hasn't been met.
I consider none of those our problem and while I am certain that Tim
would be willing and able to resolve most of the above tickets they do
not belong in our trac. When I evaluate software one of the first
things I check is their bug database and if
a) they don't have on
b) it is full of old, unresolved bugs
it immediately raises a red flag for me. I don't want this to happen
to Sage, hence no
