ATLAS developer guidelines

We're all still learning, but here are the rough guidelines that you'll need to be OK with to be added as an ATLAS SourceForge developer:

1. You only directly commit to basefiles you originate. Assuming you have written something for ATLAS before, you should have your own source to maintain. For instance, if you add some new kernels, we'll create you a subdirectory under AtlasBase/kernel. For some development, though, you will need to modify basefiles that you did not originate. For instance, if you wrote a new lapack routine, you would minimally need to modify a basefile originated by me that creates the lapack header files. For these mods, you should ideally send the basefile maintainer a patch against the basefile, which the basefile maintainer will vet and apply. If that is impractical, you will need to agree with the maintainer on a different strategy. This rule is very important, and I will tend to remove someone from the group immediately if it is violated.

2. Always leave the main CVS branch in a working, tested state. As completely unfair as it is, I (Clint) am the only guy allowed to break the main CVS branch. This means that if you have serious development you'd like to do under CVS, you need to do a developer branch until everything is working. If your mods are all to your own files, you will simply merge the developer branch back into the main once the new stuff is tested and working. If they involve other routines, then you'll need to have the person responsible for the modified codes help with the merge. So what can you apply directly to the main trunk? For instance, if you were maintaining a kernel, and you improved it, then tested (building the full gemm, running the testers, etc), and everything is OK, you could check that in after the testing and development process was done.

3. You only submit on the bug tracker for your own code. The ATLAS bug tracker serves roughly the same service for developer releases the errata does for stable: a place for all confirmed bugs. You can confirm bugs in your code, but the maintainer of the problematic code should confirm bugs in code he/she is responsible for. So, if you find what you think is a bug in someone else's code, you submit it as a support request, and the code maintainer should scope it there. If it is indeed a bug, the maintainer should move it to the bug tracker, where it will remain until fixed by a subsequent developer release. Often, these "bugs" may turn out to be misunderstandings or bad installs, and thus never get moved to the bug list.

4. When in doubt, ask. If you want to do something that you think might effect other people, ask them first. If you are not sure if you should do something, ask. If the question is general, post to the developer list. If it is delicate or personal in some way, you can send to me directly at rwhaley@users.sourceforge.net.