There's two different ways to interpret: "Your project's download page can only link to release artifacts that your PMC has approved."
It can mean: 1. "Your project's download page can only link to release artifacts. These release artifacts must have been approved by your PMC." Or it can mean: 2. "Your project's download page can link to any artifact, however, if those artifacts are release artifacts, they must have been approved by your PMC." The 2nd is the one I've been assuming, i.e., we can link to convenience binaries, which are not release artifacts (only source code is release artifacts), and the ASF is silent on the requirements, if any, for these, though I do think we need to have our own policy for this (so as to avoid anyone at all demanding the right to list their random artifact for download from our download page). Gj On Tue, Apr 14, 2026 at 11:45 AM Neil C Smith <[email protected]> wrote: > Hi, > > On Tue, 14 Apr 2026 at 06:33, Geertjan Wielenga <[email protected]> > wrote: > > 6.5 However, in practice, the Apache NetBeans project is implicitly > > vouching for the third party’s installers by listing them on the download > > page, which suggests the Apache NetBeans community should at minimum have > > some internal policy on what they require from the third party before > > agreeing to list them — even if the ASF policy doesn’t mandate it. > > This to me is a wrong interpretation of the ASF policy. In > particular, "Your project's download page can only link to release > artifacts that your PMC has approved." Release artifacts are ASF > distributed and voted on. However, when we first discussed delivering > community installers with a JDK, which means Cat-X license and > therefore not distributable here, we took wording from the httpd > project. If anything, we loosened the ASF policy a little bit, but in > a way that has precedence elsewhere. > > I think it's quite simple - community installers listed on the > download page are those aligned with the release; built and verified > by one or more PMC member, following ASF release policies as closely > as possible; and only exist for packages that for licensing reasons > cannot be distributed here. This is what they have always been, and, > if they remain, should continue to be. > > This also cannot be considered in isolation of the thread at > https://lists.apache.org/thread/w02bvdnzdorlsco2cpfyhvnkzbscydcz > covering the discontinuation of installers here at ASF, and based on > the agreement between Codelerity and FoAN at the time on transferring > these installers. > > For me, there are at least four things that have stopped the current > FoAN installers from being listed - > > - all installers must be built and verified by a PMC member, who needs > to test each package and understand and verify the various workflows > involved. That process could be split across multiple PMC members if > need be. > - the installers must not include a no-JDK option, which is not Cat-X > and should be distributed here if at all. > - the archived older versions must be on a separate page if listed at > all, which can be linked from the relevant archive pages here - we > only support current versions. > - given FoAN's use of the Apache NetBeans name, I also think the > recommended Memorandum of Understanding with the PMC needs to be > agreed first. > > I also have misgivings about the choice of JDK vendor, or older JDK > releases, or those with JavaFX. While not reasons to block listing, > they're confusing and go against our advice to always use the latest > JDK. Every set of 6 installers is also another 1-2hrs of verification > work, and I think FoAN needs to concentrate on getting one set of > compliant releases done first. > > When I started the above thread, there was understanding in the > agreement between Codelerity and FoAN that there was an ongoing budget > for infrastructure, maintenance and delivery. Since I ceased > involvement in September, this seems to have stopped too? Since then, > the only installers that we've linked to have been provided by me > mostly at personal cost, with thanks to a number of end-user sponsors. > I'm not sure either FoAN or Codelerity installers are sustainable in > the longer term on that basis, and I think we should reconsider > whether installers should be delivered via ASF again. > > I have started a thread on security-discuss about what would be > required to bring a similar process to the current Codelerity GitHub > workflow in-house, without JDK, while accessing ASF's code signing for > releases. If nothing else, it shows the level of verification that > might be required to truly do this to ASF standards. I think there's > some useful things to consider in there - > https://lists.apache.org/thread/y72098wsxxg6504mll6qkc23sq37lmcp > Anyone on the PMC here who has anything to add on that, please feel > free to! > > Thanks and best wishes, > > Neil > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
