
One other rule please,
6) Before committing code run libtbx.find_clutter and follow the output
instructions for adjusting whitespaces and imports to cctbx standards.
Nick
On Fri, Apr 12, 2013 at 8:06 AM, Nathaniel Echols
On Thu, Apr 11, 2013 at 10:20 PM, James Stroud
wrote: I'm not sure I'd emulate numpy arrays in cctbx myself, as cool as they may be. It's usually better to try to find behavior that fits the rest of the library in "look and feel". However, if I had SVN commit privileges, I'd probably use them occasionally to fix problems I find or make enhancements that would aid my work.
If you want commit access, all I need is a SourceForge user ID. Basically the only rules are:
1) Make sure your code actually compiles (to .pyc or .o) on a supported platform (e.g. a recent Mac) before checking in. (Sounds obvious, but people do forget sometimes.)
2) When changing existing functionality - even just bug fixes - always run the regression tests.
[ Ignoring (1) or (2) can and will result in changes being reverted if we can't figure out how to fix it immediately. ]
3) If you add functionality, also add a regression test if you don't want someone else to break it later.
4) Tread lightly when introducing third-party dependencies (we do this all the time, of course, but we try to do so in a way that avoids breaking the library for people who don't have the same dependency installed).
5) When in doubt, post your diffs to the cctbxbb for feedback.
There are other subtleties and complications that inevitably arise, but I'm a big fan of learning as you go, and I find long lists of rules inhibit my creativity.
-Nat _______________________________________________ cctbxbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/cctbxbb
-- Nicholas K. Sauter, Ph. D. Computer Staff Scientist, Physical Biosciences Division Lawrence Berkeley National Laboratory 1 Cyclotron Rd., Bldg. 64R0121 Berkeley, CA 94720-8118 (510) 486-5713