Ok, thanks. Then I've misinterpreted which is good. I was trying to avoid the situation where the release process wouldn't be approved by release reviewers and we would have to re-do work already done. (I'm lazy by nature). It seems this isn't written in stone and it is up to the reviewers.
Quote from Jaroslav Tulach about his experience: "On the other hand during review of HTML/Java API I had to remove download from Google Maven repository - it was seen as untrusted. I assume the same will be said about the eclipse repository." And I assume that that the HTML/Java API 3rd party lib retrieval process uses digests too. In any case it would be nice if we could have some kind assurance that what we do will eventually be approved. Understand fully that this is a grey area. If this is so, then my suggestion is that we - for now - stay on a very narrow path, pretty much as per my list. Then we are guaranteed it will not be an issue in the release review process. Overly cautious? Possibly, but I value getting a release out VERY SOON above just about everything else. Hence my suggestion. Perhaps others see it differently. my 2c Lars On Thu, Nov 2, 2017 at 10:15 AM, Bertrand Delacretaz <[email protected] > wrote: > Hi, > > On Thu, Nov 2, 2017 at 9:39 AM, Lars Bruun-Hansen > <[email protected]> wrote: > > ....it seems that for our release process to be > > approved, we must limit the location from where we fetch 3rd party libs > to > > the following... > > I don't think that's a hard requirement, but grabbing binaries from > non-standard places is not a good thing in general and might raise > questions from release reviewers. > > However, IIUC the NetBeans build strongly checks the digests of all > binaries that it uses, which makes it less of a problem. > > Downloading binaries from locations which have an uncertain future > (like hg.netbeans.org/binaries IIUC) means people might be unable to > build NetBeans in the future, and that's not good, just from a > practical and sustainability standpoint - so might be frowned upon as > well, but less so for a first incubating release. > > -Bertrand >
