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 <nechols@lbl.gov> wrote:
On Thu, Apr 11, 2013 at 10:20 PM, James Stroud <xtald00d@gmail.com> 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
cctbxbb@phenix-online.org
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