Sage Developer's Guide - Mirrors

More documents

Recommendations

Info

Sage Developer’s Guide, Release 6.1.1choose, just choose the numbered version of Sage from the menu (“sage-5.10”, for example). Type in some helpfulkeywords. In the box labeled “Assign to”, type “somebody” if you are not sure what else to do.Hit the “Preview” button to make sure everything looks okay, and then hit “Submit ticket”.If you do not have an account on the trac system to report directly, you are still encouraged to report any possible bugto the sage-devel mailing list at sage-devel@googlegroups.com. The list is moderated for new users andrequires subscription. In your bug report to sage-devel, make sure to include the following information:• operating system: as precise as possible and architecture (32-bit, 64-bit, ...)• affected version: the exact version number and the downloaded package (source, precompiled, virtual machineimage, or an upgrade from a previous version (which one?))• provide a reproducible example and/or define the steps to reproduce the erroneous behaviour.Thank you in advance for reporting bugs to improve Sage in the future!3.3 Guidelines for Opening TicketsIn addition to bug reports, you should also open a ticket if you have some new code which extends Sage’s capabilities.If you have a feature request, start a discussion on sage-devel first, and then if there seems to be general agreementthat you have a good idea, open a ticket describing the idea.When you consider opening a new ticket, please bear the following points in mind.• Before opening a ticket, make sure that nobody else has opened a ticket about the same or closely related issue.• It is much better to open several specific tickets than one that is very broad. Indeed, a single ticket which dealswith lots of different issues can be quite problematic, and should be avoided.• Be precise: If foo does not work on OS X but is fine on Linux, mention that in the title. Use the keyword optionso that searches will pick up the issue.• The problem described in the ticket must be solvable. For example, it would be silly to open a ticket whosepurpose was “Make Sage the best mathematical software in the world”. There is no metric to measure thisproperly and it is highly subjective.• If appropriate, provide URLs to background information or email threads relevant to the problem you are reporting.3.4 The Ticket FieldsWhen you open a new ticket or change an existing ticket, you will find a variety of fields that can be changed. Here isa comprehensive overview:• Reported by: The trac account name of whoever created the ticket. Cannot be changed.• Owned by: Trac account name of owner, by default the person in charge of the Component:. Generally notused in the Sage trac.• Priority: The priority of the ticket. Keep in mind that the “blocker” label should be used very sparingly.• Milestone: Milestones are usually goals to be met while working toward a release. In Sage’s trac, we usemilestones instead of releases. Each ticket must have a milestone assigned. If you are unsure, assign it to thecurrent milestone.• Component: A list of components of Sage, pick one that most closely matches the ticket.14 Chapter 3. The Sage Trac Server
Sage Developer’s Guide, Release 6.1.1• Keywords: List of keywords. Fill in any keywords that you think will make your ticket easier to find. Ticketsthat have been worked on at Sage days NN (some number) ofter have sdNN as keyword.• Cc: List of trac user names to Cc (send emails for changes on the ticket). Note that users that enter a commentare automatically substcribed to email updates and don’t need to be listed under Cc.• Merged in: The Sage release where the ticket was merged in. Only changed by the release manager.• Authors: Real name of the ticket author (or list of authors).• Reviewers: Real name of the ticket reviewer (or list of reviewers).• Report Upstream: If the ticket is a bug in an upstream component of Sage, this field is used to summarize thecommunication with the upstream developers.• Work issues: Issues that need to be resolved before the ticket can leave the “needs work” status.• Branch: See Branching Out• Dependencies: Does the ticket depend on another ticket? Sometimes, a ticket requires that another ticket beapplied first. If this is the case, put the dependencies as a comma-separated list (#1234, #5678) into the“Dependencies:” field.• Stopgaps: See Stopgaps.3.5 StopgapsIf a component of Sage produces a mathematical error, you should open two tickets: a main ticket with all availabledetails, and also a “stopgap” ticket. This second ticket should have a patch which will be merged into Sage if no onefixes the main issue; this patch should print a warning when anyone uses the relevant code. To produce the warningmessage, use code like the following:from sage.misc.stopgap import stopgapstopgap("This code contains bugs and may be mathematically unreliable.",TICKET_NUM)Replace TICKET_NUM by the ticket number for the main ticket. See trac ticket #12699, for example. On the main tracticket, you should also enter the ticket number for the stopgap ticket in the “Stopgaps” field. Stopgap tickets shouldbe marked as blockers.Note: If mathematically valid code causes Sage to raise an error or crash, for example, there is no need for a stopgap.Rather, stopgaps are to warn users that they may be using buggy code; if Sage crashes, this is not an issue.3.6 Working on TicketsIf you manage to fix a bug or enhance Sage you are our hero. See Sage Development Process for making changes tothe Sage source code, uploading them to the Sage trac server, and finally putting your new branch on the trac ticket.The following are some other relevant issues:• The Patch buildbot wil automatically test your ticket. See the patchbot wiki for more information about itsfeatures and limitations. Make sure that you look at the log, especially if the patch buildbot did not give you thegreen blob.• Every bug fixed should result in a doctest.3.5. Stopgaps 15
Page 1: Sage Developer’s GuideRelease 6.1
Page 4 and 5: 7 Indices and tables 129Bibliograph
Page 6 and 7: Sage Developer’s Guide, Release 6
Page 68 and 69:
Sage Developer’s Guide, Release 6
Page 70 and 71:
Page 72 and 73:
Page 74 and 75:
Page 76 and 77:
Page 78 and 79:
Page 80 and 81:
Page 82 and 83:
Page 84 and 85:
Page 86 and 87:
Page 88 and 89:
Page 90 and 91:
Page 92 and 93:
Page 94 and 95:
Page 96 and 97:
Page 98 and 99:
Page 100 and 101:
Page 102 and 103:
Page 104 and 105:
Page 106 and 107:
Page 108 and 109:
Page 110 and 111:
Page 112 and 113:
Page 114 and 115:
Page 116 and 117:
Page 118 and 119:
Page 120 and 121:
Page 122 and 123:
Page 124 and 125:
Page 126 and 127:
Page 128 and 129:
Page 130 and 131:
Page 132 and 133:
Page 134 and 135:
Page 136 and 137:
show all

Sage Developer's Guide - Mirrors

Create successful ePaper yourself

Delete template?

Save as template?