Revise language used regarding hosting downloads
Submitted by Wayne Beaton @wbeaton
Link to original bug (#511789)
Description
For some projects, it just doesn't make sense to host downloads on Eclipse Foundation provided infrastructure. For project like Tycho for example, distribution via Maven Central is obvious and there is no value in having any sort of standard downloadable artifact.
Random thoughts:
I would like to avoid making projects host a download on EF infrastructure "just because". If there is no segment of the project's community that will benefit from having a traditional download, then there's no value in having/hosting that download.
We do have to heed the Freedom of Action principle outlined in the Eclipse Development Process. Project teams need to have a plan in place to rehost should their hosting solution become unavailable or untenable.
Any choice of where to host artifacts must permit unencumbered access for the entire community. Consumers must not need to register (for example) to obtain project artifacts.
If EF provided hosting services can reasonably be used, they must be used. If it is simply a matter of educating the community that the artifacts are available in one place rather than another, then a plan to provide that education must be in place. It is perfectly acceptable, for example, for a project to host downloads on bintray, but the primary download site must be on the EF-provided service.
Regardless of where artifacts are distributed, the project team must keep the project's "download" information current in the PMI. Project teams may optionally provide a "downloads" page that indicates the primary source of downloads along with alternatives.
Web pages that provide pointers to download information should (must?) also include a pointer to the security policy and a link to report vulnerabilities (see Bug 496426).
Let's be sure to add entries regarding distribution of artifacts to the release review checklist (see Bug 485704).