Dear Roland:
I am not sure what my barrier is electronically, only that there is a
barrier. The web site has changed since my last attempt to make
modifications, but I still can not add to the site as I once could
when it was simply a wiki. Currently, I have a tab labeled "[MISSING:
skin.common.this-page]" and if I click on it there is an edit page
option but it is commented out, even when I am logged in.
My suggestion for the documentation and the test suite is that these
aspects of gromacs become part of the "vision" in the way that speed
is prioritized. A while back, myself and a colleague had a gromacs
pull-code extension turned down as a contribution because it would
negatively impact the overall performance of gromacs in the general
case. After I mulled that decision over for a while, I realized that
it was actually a very good and very important decision made by the
developers to keep gromacs as fast as possible over the long term even
if that meant losing out on some bells and whistles in the short term.
So I would suggest that this philosophy might be usefully applied to
code development and that modification acceptance would be dependent
on the provision of both documentation and a test suite. Not
glamorous, I know, but it's my two-cents and it's why I tend to stay
more than a year behind the release cycle with my important runs.
Thanks again,
Chris.
-- original message --
sorry I didn't pay attention (was in a hurry). I know that you have helped
with the documentation and wouldn't have suggested to you to put it on the
wiki if I recognized it was you. I thought it was a new user. And I didn't
want to criticize but only point out (to the assumed new user) that the wiki
can be improved by everyone.
Do you have suggestion of how to improve the documentation or the test
suite? What is the barrier to the wiki?
I have mentioned that before (on the dev-list) but I think a monthly phone
conference could help to coordinate those kind of issues.
Roland
On Mon, Dec 20, 2010 at 10:07 PM, <chris.neale at utoronto.ca> wrote:
<<I have changed the topic to continue a conversation that started on
"cmake --> relocation R_X86_64_32S against `a local symbol' can not be used
when making a shared object;>>
Dear Roland:
It is not my intention to be confrontational, your assistance was very
useful, I appreciate it very much, and I realize that it's not your job to
comment everything (or even answer my questions on this mailing list).
Further, I have actually contributed significantly to the gromacs wiki in
the past, but it's not a wiki anymore and the barrier to posting is enough
that I'm not the only person who has given up on it.
Second, I would like to mention that as a user I am extremely hesitant to
upgrade my gromacs version due to the lack of commenting and lack of a good
test suite. Anybody who used the free energy code with TIP4P in 2008/2009 or
used the pull code in the early versions of gromacs 4 will probably agree
with me that testing and documentation are at least as important as new
code.
I'm not asking anybody else to add documentation or test suites. I'm simply
pointing out that gromacs is falling behind in these areas and it is not
necessarily a good thing. I think that there is a utility in simply noting
this.
Sincerely,
Chris.
--
gmx-users mailing list gmx-users@gromacs.org
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at
http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
Please don't post (un)subscribe requests to the list. Use the
www interface or send it to gmx-users-requ...@gromacs.org.
Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
