Sage Developer's Guide - Mirrors

Sage Developer’s Guide, Release 6.1.1take a look. If you think there are issues with the patch, explain them in the comment box and change the status to“needs work”. Browse the tickets on the trac server to see how things are done.Note: “The perfect is the enemy of the good”The point of the review is to ensure that the Sage code guidelines are followed and that the the implementation ismathematically correct. Please refrain from aditional feature requests or open-ended discussion about alternativeimplementations. If you want the patch written differently, your suggestion should be a clear and actionable request.3.8 Closing TicketsOnly the Sage release manager will close tickets. Most likely, this is not you nor will your trac account have thenecessary permissions. If you feel strongly that a ticket should be closed or deleted, then change the status of the ticketto needs review and change the milestone to sage-duplictate/invalid/wontfix. You should also comment on the ticket,explaining why it should be closed. If another developer agrees, he sets the ticket to positive review.A related issue is re-opening tickets. You should refrain from re-opening a ticket that is already closed. Instead, opena new ticket and provide a link in the description to the old ticket.3.9 Reasons to Invalidate TicketsOne Issue Per Ticket: A ticket must cover only one issue and should not be a laundry list of unrelated issues. Ifa ticket covers more than one issue, we cannot close it and while some of the patches have been applied to a givenrelease, the ticket would remain in limbo.No Patch Bombs: Code that goes into Sage is peer-reviewed. If you show up with an 80,000 lines of code bundle thatcompletely rips out a subsystem and replaces it with something else, you can imagine that the review process will bea little tedious. These huge patch bombs are problematic for several reasons and we prefer small, gradual changes thatare easy to review and apply. This is not always possible (e.g. coercion rewrite), but it is still highly recommendedthat you avoid this style of development unless there is no way around it.Sage Specific: Sage’s philosophy is that we ship everything (or close to it) in one source tarball to make debuggingpossible. You can imagine the combinatorial explosion we would have to deal with if you replaced only ten componentsof Sage with external packages. Once you start replacing some of the more essential components of Sage thatare commonly packaged (e.g. Pari, GAP, lisp, gmp), it is no longer a problem that belongs in our tracker. If yourdistribution’s Pari package is buggy for example, file a bug report with them. We are usually willing and able to solvethe problem, but there are no guarantees that we will help you out. Looking at the open number of tickets that are Sagespecific, you hopefully will understand why.No Support Discussions: The trac installation is not meant to be a system to track down problems when using Sage.Tickets should be clearly a bug and not “I tried to do X and I couldn’t get it to work. How do I do this?” That is usuallynot a bug in Sage and it is likely that sage-support can answer that question for you. If it turns out that you didhit a bug, somebody will open a concise and to-the-point ticket.Solution Must Be Achievable: Tickets must be achievable. Many times, tickets that fall into this category usually ranafoul to some of the other rules listed above. An example would be to “Make Sage the best CAS in the world”. Thereis no metric to measure this properly and it is highly subjective.3.8. Closing Tickets 17