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:
- 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.
- 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.
- 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.
- 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