§ Development

• The first time, run make build. DO NOT RUN make, as this performs a make docas well which burns cycles building docs for no reason.
• Normally, if you just change Python code in the library, it suffices to run ./sage -brto update Python.
• Only if you changed docs, and want to test that they still work, you'd need to run make, or make doc-html
• To run doctests, can run ./sage -t . More info on the sage doctesting page
• make build && ./sage -n=jupyter ./test-ddg-notebook.ipynb is reasonably fast.

• SAGE developer index
• Baby's first Trac ticket: #31248 --- Make tableaux error messages more precise

§ Git the hard way for SAGE

• Git the hard way

git with SAGE uses different URLs for fetch and push.

[user@localhost sage]$ git remote add trac git://trac.sagemath.org/sage.git -t master[user@localhost sage]$ git remote set-url --push trac git@trac.sagemath.org:sage.gittrac        git://trac.sagemath.org/sage.git (fetch)trac        git@trac.sagemath.org:sage.git (push)

• I use my github account to develop for SAGE.
• Linking your SSH key with sage-trac

§ Getting the commit merged

The release manager (Volker Braun) takes care of it. A number of people can close tickets for invalidity/duplicate etc, but the actual merging is done by one person only (and a number of bots/scripts that help).

A positively reviewed ticket with green bots and all fields filled in will usually be merged in a week or two or rejected (merge conflict, issues with specific architectures, failing bots). But it might take longer (too many positively review tickets waiting, end of release cycle).

§ Tending to the garden

• Fix typos
• Fix pep8, pyflakes, lint warnings. Try to simplify code that's marked very compliated by radon.
• Fix code that's marked by lgtm