[gmx-users] compilation instructions, the gromacs wiki, documentation, and test suites

[chris.neale at utoronto.ca]

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