[Pw_forum] Change in the behavior of "Reply"

Paolo Giannozzi giannozz at democritos.it
Fri May 18 12:25:23 CEST 2012


Please note that the behavior of this mailing list with 
respect to the "Reply" command has been reverted to the 
previous "Reply-to munging" option, that is: if you hit 
"Reply", the message will go to the mailing list, not to 
the poster. So please THINK before hitting "Reply" (think
EVEN MORE before hitting "Send"), avoid unnecessary or
inappropriate traffic in this mailing list.

Here is a reminder of the guidelines for posting:

Before posting, please: browse or search the archives – links are
available in the Contacts page of the quantum ESPRESSO web site.
Most questions are asked over and over again. Also: make an attempt to
search the available documentation, notably the FAQ, the User Guide, 
and the Input Data Description. The answer to most questions is already
there.
      * Sign your post with your name and affiliation.
      * Choose a meaningful subject. Do not use “Reply” to start a new
        thread: it will confuse the ordering of messages into threads
        that most mailers can do. In particular, NEVER use “Reply” to a
        Digest!!!
      * Be short: no need to send 128 copies of the same error message
        just because this is what came out of your 128-processor run. No
        need to send the entire compilation log for a single error
        appearing at the end.
      * Avoid excessive or irrelevant quoting of previous messages. Your
        message must be immediately visible and easily readable, not
        hidden into a sea of quoted text.
      * Remember that even experts cannot guess where a problem lies in
        the absence of sufficient information. One piece of information
        that must always be provided is the version number you are
        using.
      * Remember that the mailing list is a voluntary endeavour: nobody
        is entitled to an answer, even less to an immediate answer.
        Please check in the archive if your e-mails have gone through
        before thinking or even worse complaining that nobody is
        answering my questions.
      * Finally, please note that the mailing list is not a replacement
        for your own work, nor is it a replacement for your thesis
        director’s work.

Reporting BUGS

      * Problems should be reported to the pw_forum mailing list, NOT to
        a single developer
      * Before reporting an unexpected behavior as a problem, 
              * check your input data: most problems originate from
                there
              * if you have a problem with examples, look for the error
                message printed by the code in the output file: few
                things irritate developers  like messages saying "I got
                error 137 in example 24", or "What does error # 1924
                mean?"
              * carefully read the error message issued by the code, if
                present: sometimes it explains everything. For the
                provided examples, you must look inside the output
                files.
              * trust the code if it says "this doesn’t exist" or "this
                is wrong"!
              * check if a similar or same problem hasn’t already been
                reported
      * Before deciding that a problem is due to a bug in the codes,
        verify if it is reproducible on different
        machines/architectures/phases of the moon: erratic or
        irreproducible problems, especially in parallel execution, are
        often an indication of buggy compilers or libraries
      * Bug reports should preferably be filed using the bug tracking
        facility of qe-forge.org:
        http://qe-forge.org/tracker/?group_id=10
      * Bug reports should include enough information to be reproduced,
        e.g. version number (mandatory!), hardware/software
        combination(s) for which the problem arises, whether it happens
        in serial or parallel execution or both, and, most important, an
        input and output exhibiting such behavior (fast to execute if
        possible). The error message alone is usually not a sufficient
        piece of information. Segmentation violation or obscure MPI
        error messages are NEVER a sufficient piece of information. 
-- 
Paolo Giannozzi, IOM-Democritos and University of Udine, Italy





More information about the users mailing list