RFE based on feedback from gfortran mailing list

[rouson]

Avg response time

Request for Enhancement (RFE)

The following list of steps might improve the installation experience based on user feedback posted to the gfortran mailing list:

• 1. Add sample arguments to the output of install.sh --help or install.sh -h
• 2. Reduce INSTALL.md to just describing one recommended installation method, including one or two command-line examples and possibly a printout of the installer help page. Split everything off to a separate page.
• 3. Merge pull request Merge issue-422-implement-by-refs #477 into the master branch.
• 4. Let the installer default to using any GCC with version >= 5.0.0.
• 5. Produce a new release as soon as 3 and 4 happen.
• 6. Investigate the MPI wrapper issues described in the user feedback.
• 7. More prominently display the advice to read Markdown files online in a browser (or restrict the use of advanced GitHub-flavored Markdown when it inhibits the legibility of the raw text outside a browser).

Regarding item 1, our installation documentation has become bloated by attempts to respond to a multitude of user requests for different installation methods. We should probably adopt recommend method (presumably CMake) and give a terse but complete example of how to use that method in the INSTALL.md file. All other methods should be in a separate file with a clear warning that the user adopts these at their own risk and with various associated limitations.

[rouson]

Commit 633f251 implements item 4.

[zbeekman]

@rouson RE 6. above: We did this right? We removed the emergency warning/error when the c compiler being wrapped by MPI is different than GCC/the C compiler specified by the user. Is there anything else that needs to be done for 6. or can we mark it as done? If so, let's close this issue and I'll mint a release ASAP.

[zbeekman]

Fixed in PR #479

[rouson]

@zbeekman I just unchecked item 5 and reopened this because we still haven't released so this issue is our reminder of the need to so soon because of the number of enhancements and bug fixes that have not yet made it into a release. Let's see if we can get a release shortly. At this point, I think we should decide that anything that appears to be holding up a release won't happen. That even includes the drafting of complete release notes (which I agreed to do). A release with minimal or no notes is better than no release.

[zbeekman]

Done: https://github.com/sourceryinstitute/OpenCoarrays/releases/tag/2.0.0-rc1

However, the release notes probably need some more attention.