You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is part of the review in openjournals/joss-reviews#1370. If I missed something in the docs that addresses the comments below, please let me know.
Although I had no trouble building the code, I did not find anywhere that mentioned dependencies or prerequisites for building. For example, the first thing in Make.defs is to check for python >= 2.7. Does that imply that the code will work with python 3? Furthermore, are you using modern-enough C++ or Fortran features that require std flags to be set with compilers? Again, I had no troubles using system GNU tool chain and system python when I tested, but it might be useful to say that one needs, for example, a C++-11 compiler.
Regression/unit testing: there didn't seem to be any mention of it except on the README stating that for the development -> master "merge to take place, we need to be passing the regression tests." Can I, as a user, run these tests? If so, how? If I want to contribute and I cannot run the tests, how do I ensure my contribution doesn't break something, or how do I add new tests? Is amrex using typical GitHub CI workflows, or is it something in-house? Documentation addressing these types of questions would be extremely beneficial to someone that wants to contribute.
Contributing / Reporting Bugs / Asking questions: the model adopted (fork + PR to development) for user contributions is well outlined in the README and the website, with the caveat of testing mentioned above. Although it is on the website, it would be nice to have the README mention that bugs should be reported by filing GitHub Issues; also mention that the mechanism for asking general questions is through GitHub Issues.
"Core developers": The README has the criteria listed for being considered a core developer, but I didn't actually see a list of current core developers, unless I am to take those in the zenodo file as core developers. If it is intentional to not list the core developers, then its unclear the need to even describe the criteria for becoming one.
The text was updated successfully, but these errors were encountered:
This is part of the review in openjournals/joss-reviews#1370. If I missed something in the docs that addresses the comments below, please let me know.
Although I had no trouble building the code, I did not find anywhere that mentioned dependencies or prerequisites for building. For example, the first thing in Make.defs is to check for python >= 2.7. Does that imply that the code will work with python 3? Furthermore, are you using modern-enough C++ or Fortran features that require std flags to be set with compilers? Again, I had no troubles using system GNU tool chain and system python when I tested, but it might be useful to say that one needs, for example, a C++-11 compiler.
Regression/unit testing: there didn't seem to be any mention of it except on the README stating that for the
development
->master
"merge to take place, we need to be passing the regression tests." Can I, as a user, run these tests? If so, how? If I want to contribute and I cannot run the tests, how do I ensure my contribution doesn't break something, or how do I add new tests? Is amrex using typical GitHub CI workflows, or is it something in-house? Documentation addressing these types of questions would be extremely beneficial to someone that wants to contribute.Contributing / Reporting Bugs / Asking questions: the model adopted (fork + PR to
development
) for user contributions is well outlined in the README and the website, with the caveat of testing mentioned above. Although it is on the website, it would be nice to have the README mention that bugs should be reported by filing GitHub Issues; also mention that the mechanism for asking general questions is through GitHub Issues."Core developers": The README has the criteria listed for being considered a core developer, but I didn't actually see a list of current core developers, unless I am to take those in the zenodo file as core developers. If it is intentional to not list the core developers, then its unclear the need to even describe the criteria for becoming one.
The text was updated successfully, but these errors were encountered: