Telcon: 2016 06 16

Participants

1. Matt Belhorn (ORNL)
2. Ben Boeckel (Kitware)
3. Mike Collette (LLNL)
4. Elizabeth Fischer (NASA)
5. Robert French (ORNL)
6. Jim Galarowicz (Krell)
7. Todd Gamblin (LLNL)
8. Patrick Gartung (Fermi)
9. Kenneth Hoste (HPC U. Ghent)
10. Greg Lee (LLNL)
11. Matt Legendre (LLNL)
12. Erik Schnetter (Perimeter)
13. Peter Scheibel (LLNL)

News

1. newarch is (finally) merged to develop!

• Thanks to Mario and Greg!

• Adds Cray support.

• Adds module-loaded compilers.

• Adds concepts of platform / os / target to specs

  • platforms can have frontend and backend operating systems
    • e.g. sles11, CNL10, elcapitan, yosemite, sierra, rhel6, rhel7
  • OS's can have targets (e.g., x86_64, haswell, ivybridge)

• compilers.yaml no longer hierarchical; has per-compiler compiler: entry.

• Install layout is changed

• I expect there will be a few bugs to shake out, but they should hopefully not be major ones that require a lot of rebuilding or incompatibility between versions.

• Things to expect:

  • this update will create installations that are not compatible with older versions of Spack.
    • new compilers.yaml
    • new fields in spec.yaml files in installation directories.
  • hashes of the "same" package will be different, so you'll need rebuilds.
  • architecture replaced with platform/os/target, so you may need to revise packages
    • tried to revise the ones in the mainline.
    • New way to check for mac os x: spec.satisfies('platform=darwin')
  • install layout changed -- no more SYS_TYPE.
    • install layout now reflects the new architecture.

1. Next large(ish) PR: build dependencies

2. spack find no longer shows variants by default

• add -v flag to get the variants
• packages like boost can make the variant view awkward
  • Improved padding for packages with lots of variants.

1. How to release things in a more stable way?

• Spack releases are probably too infrequent
  • see post on the mailing list
  • Releasing at well-defined times seems like a good idea, but a release should also imply a certain level of testing and reliability.
    • need to integrate testing with the release process; currently not automated enough to do it frequently.
• Reasons:
  • Getting build bot setup at LLNL has been slow -- this will help.
  • Proper build tests are a must for long-term stability
    • Need multi-arch, multi-compiler testing and notion of what is stable.
      • platform-specific packages.yaml can help with this.
        • sensible defaults, per-platform "stable" stack at any time.
    • Currently we really only do unit tests via travis
      • Other build tests rely on the devs and community
• Plan going forward: focus on getting real build testing up and running.

1. Corporate Sponsorship

2. Flake8 hate

• need to:
  1. document the process for users to run flake8 themselves
  • boils down to: run share/spack/qa/run-flake8*
  • this should be made into a spack command.
  1. make a pass over the repo to flake8-ify things.
  2. Change to 100-column line limit