On Mon, 8 Jun 2026 at 02:36, Michael Bien <[email protected]> wrote: > This means that the second option ("Bring back into ASF") would be possible > without disrupting downstream packaging since the JDK could be moved into a > dependency (if it isn't already one like with AUR and flathub).
Possibly. You and I are amongst PMC members who have raised concerns about FoAN shipping unsupported JDK combinations. With the zip bundle it is very obviously designed to allow the end user to choose which JDK to run the IDE with. With packages like that we would need to be careful how the JDK dependency is resolved, particularly if the installation makes this more difficult to configure (eg. netbeans.conf being read-only). We sometimes had issues with this before. It's worth noting Laszlo's comment on a recent Snap issue about the benefit of moving that outside of ASF so that the JDK dependency could be included - https://github.com/apache/netbeans/issues/9392#issuecomment-4558885625 > Of course the signing problem remains + someone would have to do that task > during release which is already full with other tasks (looking at the new, > slightly intimidating checklist). For anyone interested, Eric's checklist of tasks for the current release process is at https://github.com/apache/netbeans-jenkins-lib/issues/146 We were joking about how all this is the short version since https://lists.apache.org/thread/w02bvdnzdorlsco2cpfyhvnkzbscydcz when we dropped both installers and the update centers. This reduced some of the release overhead. The update centers were a significant job to remove. The macOS installer was the bigger installer overhead, as it was the only one that had to be built and signed manually. If we were to bring installers back into ASF, we could use a workflow like the one I currently use for the community installers - https://github.com/codelerity/netbeans-packages That is the subject of the discussion on the security-discuss list. That builds and signs every installer in about 5min. The workload is making a process like that ASF compliant to access the foundation's code signing. The additional release overhead is there, but would be less than our previous process. Testing and gpg sign off for vote would probably need to be shared out. The other point I would make is that a PMC member has been doing that task during the release process for the last 18 months - me! FoAN was meant to be providing infrastructure for PMC members to share access to things that cannot be done within ASF. Assuming that is made to work as intended, the release overhead should be similar whether it's done internally or externally. Whether we can actually do that with our current resources is part of this conversation. Option #1 is the only one that removes workload. 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
