I'm happy to see so much interest and passion about how to make Amber better,
but we need some ground rules, before productive discussions become
flame wars:
1. Please don't post things that can be construed as attacks of other
developers. Go out of your way to be polite, and edit your posts (before
hitting "send") with this in mind.
2. Keep your posts short and on-topic. It helps to see the gist of
ideas for making things better, but at this stage the details of the
implementation can be a distraction. If you really need a lot of space,
use an attachment to hold the details.
3. I think the general outline of what will happen with Amber12 is actually
pretty clear, and doesn't involve radical changes:
a. AmberTools will still exist (because people are used to it, and because
a growing number of projects outside of Amber make use of it.)
b. Amber will still exist, as a paid-for entity, but our goal is to make
the combination of Amber+AmberTools as useful as possible to ourselves
and to the community, not to maximize the revenue we receive.
c. I'm leaning towards keeping sander as a part of Amber. It would be
considerably simpler to move it to AmberTools (as Jason, Tyler,
Taisung and I have argued), but this might represent a bigger change
than we want to tackle right now. Comments on this item are welcome
(consistent with points 1 and 2 above), but mainly from those who
have not already weighed in on this topic before.
d. We can take useful steps to simplify the building and testing of our
codes. A lot of this can be done by improving the Makefiles and scripts
we already have. Jason has some good ideas about how to manage bugfixes
and updates. Bigger changes (cmake might be an example) can be
considered, but time is short.
e. Having a bias toward reducing the number of separate programs is fine,
but each project is different, and I don't see us changing from offering
a "package of molecular simulation programs" that work reasonably well
together. It's unfortunate but probably telling that (aside from
Romain) we've not had a single comment about improving the documentation
or the tutorials. Limitations there are probably more harmful to users
than are any bad decisions about programming languages or about how
and where to implement some new feature.
OK, I've violated my own rule about keeping posts short...just shows how
useful "rules" are for Amber developers.... :-)
...dac
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Fri Nov 04 2011 - 20:30:02 PDT
