Telcon: 2016 09 22

Participants

One near-term, maybe early October
One version right before SC16, to use for the tutorial.
Upstream is moving faster now so we'll fork a release branches then merge to master when complete.
- for previous releases we could just harden develop and merge.
focus on reducing bugs/gotchas and making Spack experience smoother
- especially want to make startup easier on BG/Q, Cray.
- need more works-out-of-the-box there.

Trying to clear out the backlog
#1682 Reworking of lapack_shared_libs and similar properties
- sets up more consistent ways of determining libraries for different lapack/blas/etc. implementations
- good basis for protocol for accessing lib names of dependencies (see #1821)

tried to make a large initial set -- people seem to be using them:
- https://github.com/LLNL/spack/labels

would like to have a wider discussion of project structure -- this is preliminary.
GitHub has a lot of new features for project management
- Will probably start using projects for releases.
- Might want to document PR review/approval policies.
- Favor a liberal contribution policy but make sure Spack is still safe.
Opening up write permissions (except on develop and master) has worked well.
- people are labeling issues and PRs, which helps a lot w/managing them (please do more of this)
- much easier to scan the PR list.
Will start adding more core contributors with write permissions to curate issues, PRs, etc.

was gone to Taiwan for CLUSTER'16 -- didn't get as much time to fix these as would've liked.
These need to be fixed for release, will be added as release blockers in a github project.

@citibeth: For now, I'd like to focus on fixing bugs and problems in the features we have. I've run into a LOT of little "gotchas"...

I want to use Spack by putting all my preferred variants and versions in packages.yaml. Have others tried this? I think it's a great way to go because it cleans up your spack install command lines; I like it a LOT better than before this was possible. But my attempts to use Spack this way have uncovered a ton of bugs. See:
#1768: [Bug] type='build' specs conflict when they shouldn't
#1556: preferred=True overrides packages.yaml (and it shouldn't)
#1555: Serious Bug with openssl, @system

@citibeth: This relates to #1556 above and #1561 below. The problem is... what is the right concretization algorithm? And how does this interact with the sorting of version numbers? This algo needs to integrate version information from multiple sources and integrate it into choosing the "right" version. Sources include:
Versions listed in package.py
The "preferred=True" flag on one more versions from (a)
Versions listed in packages.yaml
Version information from the command line

Can Spack use versions not listed in package.py. Maybe yes; but I don't think that's a useful feature. When things scale, essentially all versions must be verified.

yes, but it warns you.
verification is good but so is quickly trying a new release. This feature isn't really hurting much... as long as there is a warning.

Currently, not enough versions are coming INTO the concretization algo from (a); it looks like only the top 3 versions are coming. This produces incorrect results if the user has requested an older version in packages.yaml. This is a real bug, but it's not been submitted (workaround is to comment out versions I don't intend on using).

@citibeth: Special treatment of @develop thing feels like a hack. I'd like to think more about a general way to create a version number ordering that's predictable and obvious. But first, I think it's important to get the existing bugs fixed.
- @tgamblin: me too, though it's not the worst hack.

@citibeth started discussion on spack security model
- @tgamblin: we've talked about a lot of this on telcons -- making git/svn/hg more secure seems like the priority but there is more to do (w/binary caching, etc.)