Should we remove the downloads provided by the builders?

[zoddicus]

trafficstars

Points I can immediately think about this:

Reason to remove:

1. These builds are not pegged to any specific release, instead they are just most recent build that has succeeded. Thus are not particularly stable and could lead to unreproducible builds.
2. They have not undergone any QA.
3. No workflow that we actively maintain/care about depends on them.
4. In general they are not considered supported.
5. We don't have the resources/appetite to support them formally.

Reason to keep:

1. Desire to supply users with a simple artifact.
2. Some users, maybe, already have workflows that depend on these binaries.

I am personally of the opinion that this is a situation where a partial solution is worse than no solution. The downloads are not really intended to be production ready nor supported, but a number of recent bugs suggest that users are attempting to integrate them into their workflows as a blackbox solution. This is leaving them in an awkward position when there are issues, since we are unwillingly to fix bugs, but since they are not building it themselves so it is difficult for them to fix it themselves.

An alternative might be to remove various libraries from the downloads, and only ship the user land executables, if those are desired by people. I think if someone is wanting to use the libraries in their project, taking an untested random blob from the internet is the wrong way to do it, building the libraries should be part of their work flow.

[zoddicus]

@dj2 @dneto0 thoughts?

[Ralith]

As a user, I'd very much like to have a prebuilt stable version I could reference from CI scripts. The current downloads aren't useful for that partly because they're unstable, but even moreso because a download URL hidden in a HTML redirect is incredibly difficult to fetch from a script.

[dj2]

Isn't that just the VulkanSDK?

[Ralith]

That includes quite a lot of stuff I don't need, and seems to be hidden behind similarly obfuscatory javascript besides.

[ben-clayton]

This is something I'm actively looking into for multiple projects. Assigning to myself.

[j3parker]

As a user, (1) would be helpful for me, but (2)/(4) are not particularly important beyond supporting these URLs returning a consistent payload for a reasonable amount of time. In general using third-party software the expectations around QA or support are fairly low 😄

My use case involves using Bazel. It would be most convenient (in lieu of this repo using Bazel itself) to download pre-built binaries. This is done by providing a URL and (rightfully) a hash, so determinism is vital. I can host the binaries myself, but if I wanted to share my rules/build with other people it would be preferable to use "official" URLs (it would look less suspicious.)

Additionally, if there was a way to enumerate the builds/releases programmatically, it would be easy for me to keep my rules up to date (via automated PRs).

I understand the merits of (3)/(5).