discuss third-party release asset tarballs vs those revision controlled the the repo proper

[cyrush]

Describe the bug

build_visit pulls from release assets that are tied to each release.

We should also be revision controlling those in lib, but they can get out of sync.

We should discuss

[markcmiller86]

I see a few options here...

• Downloading from a release asset
• Downloading from a specific branch
• Downloading from only the master branch

FWIW, I favor the branch option. That is, we create release branches in third-party which are 1:1 with release branches in visit-dav and then put the associated tarballs in lib folder there. That does complicate, slightly, the construction of the URL for the download. Because third-party tarballs tend to be named with their own distinct version numbers, each can remain within the same branch without collision which means the only master branch approach would work fine too.

A challenge I see with using release assets for this is that the release in third-party needs to be created long before the release is actually made...like maybe months. And, it is not revision controlled. It isn't as easy to know when some developer has potentially changed something. Finally, I am not sure how release assets work when trying to keep a repo across an air-gapped network in sync. I think it would be nice to be able to have that option and the release assets approach essentialy defeats that.

[cyrush]

I think we could have an approach that uses parallel branches to our RC ones. (like you suggest)
But to support all versions tied to an RC, we would only grow the branch (we would not remove tarballs)

Also important:
Since they are static, release assets don't count against github data quota -- it's better to pull from there even if we can construct the proper urls for lfs content.

[cyrush]

discuss at future special topics meeting

[cyrush]

Current behavior:

tpl tarballs are fetched from https://github.com/visit-dav/third-party/releases using the root minor release number for example,
for 3.4.2 release assets of 3.4.0 -- fetch does not use lfs

if they aren't found, there is backup path that looks at the master branch of the repo:
https://github.com/visit-dav/third-party/raw/master/lib -- this fetches via lfs

TODO:

• Create a release page to hold assets for each minor series (3.5) -- this can happen before we actually release visit
• Clean up the tpl repo to remove old versions of tpls as part of 3.5 release
• have a tool to audit if tpl sources are needed ? this is complex b/c we expect the list to grow with patch releases
• do better with: Add list preferred deps for all TPLs to release notes #19226

[markcmiller86]

Given GitHub's new billing model for LFS bandwidth, hosting third-party libraries as assets is definitely the way to go because downloads of these are not currently usage charged.