Re: Signing the Apache way Re: [DISCUSS] Handling release updates
Hi all, Excuse my confusion regarding this. So what we need is to sign the NBMs using our PGP keys, right? I mean, use our PGP keys for release builds and using some other PGP keys for development builds,. Thanks, Antonio El 10/11/19 a las 14:16, Jaroslav Tulach escribió: Can’t we change/enhance the way we do signing? 1. If there is an .asc file next to the .nbm one, then use it to verify the NBM. Search https://www.apache.org/dist/netbeans/KEYS to get list of approved keys. Display trusted, if .asc file is OK. 2. If the NBM comes from Maven central, but isn’t listed among trusted keys, then verify the .asc file and display “signed by 3rd party” With such check in, we don’t need to change existing processes. All Apache released NetBeans bits will be signed by default. We have just one “technical” problem: we need somebody(!) to write the code. -jt PS: This doesn’t solve the current 11.2 problem. 8. 11. 2019 v 11:53, Neil C Smith : On Fri, 8 Nov 2019, 10:35 Geertjan Wielenga, wrote: How is the signing done for Apache NetBeans during releases and why can't that be used for the patch too? Different kinds of signing. The releases and the updates will be signed as ASF requires with an external .asc file. But the nbms in the release aren't currently jar signed (ie. internal signature) so will show as unsigned with a warning in the IDE. You can see this if you uninstall and reinstall modules in the IDE. This is what we need to sort out. And yes, you're not the only one to have been confused by this distinction! ;-) Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Signing the Apache way Re: [DISCUSS] Handling release updates
Can’t we change/enhance the way we do signing? 1. If there is an .asc file next to the .nbm one, then use it to verify the NBM. Search https://www.apache.org/dist/netbeans/KEYS to get list of approved keys. Display trusted, if .asc file is OK. 2. If the NBM comes from Maven central, but isn’t listed among trusted keys, then verify the .asc file and display “signed by 3rd party” With such check in, we don’t need to change existing processes. All Apache released NetBeans bits will be signed by default. We have just one “technical” problem: we need somebody(!) to write the code. -jt PS: This doesn’t solve the current 11.2 problem. > 8. 11. 2019 v 11:53, Neil C Smith : > > On Fri, 8 Nov 2019, 10:35 Geertjan Wielenga, wrote: > >> How is the signing done for Apache NetBeans during releases and why can't >> that be used for the patch too? > > Different kinds of signing. The releases and the updates will be signed as > ASF requires with an external .asc file. But the nbms in the release aren't > currently jar signed (ie. internal signature) so will show as unsigned with > a warning in the IDE. You can see this if you uninstall and reinstall > modules in the IDE. This is what we need to sort out. > > And yes, you're not the only one to have been confused by this distinction! > ;-) > > Best wishes, > > Neil
Re: [DISCUSS] Handling release updates
On Fri, 8 Nov 2019, 10:35 Geertjan Wielenga, wrote: > How is the signing done for Apache NetBeans during releases and why can't > that be used for the patch too? > Different kinds of signing. The releases and the updates will be signed as ASF requires with an external .asc file. But the nbms in the release aren't currently jar signed (ie. internal signature) so will show as unsigned with a warning in the IDE. You can see this if you uninstall and reinstall modules in the IDE. This is what we need to sort out. And yes, you're not the only one to have been confused by this distinction! ;-) Best wishes, Neil >
Re: [DISCUSS] Handling release updates
How is the signing done for Apache NetBeans during releases and why can't that be used for the patch too? Sorry, ignorant on this point and need to understand this aspect to be able to participate in the discussion, alternatively those who are familiar with this should take the lead and do what is needed or what is best under the circumstances. Gj On Thu, Nov 7, 2019 at 6:22 PM Neil C Smith wrote: > On Thu, 7 Nov 2019 at 17:05, Korney Czukowski wrote: > > Although even with almost > > everything in place, there's still this issue with nbm signing, so > > practically the Update Center cannot be used for now, right (else you > > would have already used it)? If this is the case, then a (trusted) > > offline installed could be used as a temporarily and somewhat ugly > solution. > > The UC is useful now, and can be used for things like RCP harness > building. However, the iDE will show a warning for nbms there. > > All binary elements, including the zips and nbms, are already gpg > signed locally. We just need a temporary solution to (jar) sign the > updated nbm files as well. The solution you suggest would actually be > more complicated not less. We still have to sign them! Getting them > in the existing UC is easy after that. > > Thanks, > > Neil > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
Re: [DISCUSS] Handling release updates
On Thu, 7 Nov 2019 at 17:05, Korney Czukowski wrote: > Although even with almost > everything in place, there's still this issue with nbm signing, so > practically the Update Center cannot be used for now, right (else you > would have already used it)? If this is the case, then a (trusted) > offline installed could be used as a temporarily and somewhat ugly solution. The UC is useful now, and can be used for things like RCP harness building. However, the iDE will show a warning for nbms there. All binary elements, including the zips and nbms, are already gpg signed locally. We just need a temporary solution to (jar) sign the updated nbm files as well. The solution you suggest would actually be more complicated not less. We still have to sign them! Getting them in the existing UC is easy after that. Thanks, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
Then I must have misunderstood your earlier comment about issues due to changes in the build system, my apologies. Although even with almost everything in place, there's still this issue with nbm signing, so practically the Update Center cannot be used for now, right (else you would have already used it)? If this is the case, then a (trusted) offline installed could be used as a temporarily and somewhat ugly solution. And yes, I meant generally any release within the quarterly cycle that is assigned a version number, sorry for not being clear. Regards! On 2019/11/07 16:24:54, Neil C Smith On Thu, 7 Nov 2019 at 16:14, Korney Czukowski If the Update Center is out of the question for now, it isn't! That bit is not the problem. The only problem to delivery at the moment is signing the nbm with a certificate that's trusted by the IDE. Of course, both options should be viewed only as a temporary solution for situations where you guys really want to push an update ASAP. IMO, the end goal should be that any module that NetBeans platform can possibly live without, can be installed or updated from the Update Center by default, and the incremental releases with the version numbers would just include the most recent stable versions of those modules. That is already the case, although not quite sure what you mean by incremental releases - note that 11.2. is not an incremental release. There is just the issue again that the nbms in that distribution update centre are not signed at present. eg. 11.2 is all at https://dist.apache.org/repos/dist/release/netbeans/netbeans/11.2/nbms/ Longer term the Apache mirrors may not be the best way to distribute the modules though. Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
On Thu, 7 Nov 2019 at 16:14, Korney Czukowski wrote: > If the Update Center is out of the question for now, it isn't! That bit is not the problem. The only problem to delivery at the moment is signing the nbm with a certificate that's trusted by the IDE. > Of course, both options should be viewed only as a temporary solution > for situations where you guys really want to push an update ASAP. IMO, > the end goal should be that any module that NetBeans platform can > possibly live without, can be installed or updated from the Update > Center by default, and the incremental releases with the version numbers > would just include the most recent stable versions of those modules. That is already the case, although not quite sure what you mean by incremental releases - note that 11.2. is not an incremental release. There is just the issue again that the nbms in that distribution update centre are not signed at present. eg. 11.2 is all at https://dist.apache.org/repos/dist/release/netbeans/netbeans/11.2/nbms/ Longer term the Apache mirrors may not be the best way to distribute the modules though. Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
If the Update Center is out of the question for now, maybe it would be feasible to create an offline update installer consisting only of a couple of nbms that need to be updated, that would update an existing NetBeans installation? Then it should be possible to vote for just for this very limited portion of the sources and avoid issues with early merging. If the installer is signed, there should not be any trust issues regarding the content it carries. If this is hard to do, maybe even just posting the patched nbms somewhere and instructing the affected users how to replace them manually could suffice, given the NetBeans userbase profile, it might be acceptable to many. Of course, both options should be viewed only as a temporary solution for situations where you guys really want to push an update ASAP. IMO, the end goal should be that any module that NetBeans platform can possibly live without, can be installed or updated from the Update Center by default, and the incremental releases with the version numbers would just include the most recent stable versions of those modules. On 2019/11/07 10:56:49, Neil C Smith wrote: > On Thu, 7 Nov 2019 at 10:43, Geertjan Wielenga wrote:> > > Can someone -- preferably Eric, Neil, Laszlo, Jan, or Matthias, suggest a> > > way forward to get an update out, i.e., we could even call it 11.2.1,> > > maybe, if we can't figure out how to release the two modules (what would be> > > the problem with doing it as Laszlo did for Gradle)?> > > We can't do it as Laszlo did for Gradle because of changes in the> > build system. And in many respects this should be simpler.> > > We need to> > > * merge the relevant PRs to master and test. (perhaps provide nbms via> > temporary UC?)> > * (ideally) cherry pick locally and open new PRs on top of release112> > (better than pushing to release branch IMO because of Travis, etc.)> > * Merge to release branch.> > * write the hash into the release JSON file (probably 11.2-patch1) and> > trigger a build.> > * ***somehow*** sign the relevant nbms.> > * vote on source zip and required nbms.> > > There is one more potential PR for the patch update. They all have> > Cherry Pick labels on them.> > > https://github.com/apache/netbeans/pulls?q=is%3Apr+is%3Aopen+label%3A%22Cherry+Pick%22> > > I'm happy to RM the process from point 3, but I'd rather the current> > PR authors handled steps 1 and 2. If I do, add me as a reviewer on> > the step 2 PR when they're ready.> > > And we still need an answer for the signing part for 11.2 updates -> > perhaps the web signing via Apache is the way, but I'll need to follow> > up with infra. Few suggestions for 11.3+ are great there but don't> > help us with this update.> > > Best wishes,> > > Neil> > > -> > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org> > For additional commands, e-mail: dev-h...@netbeans.apache.org> > > For further information about the NetBeans mailing lists, visit:> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists> > - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
On Thu, 7 Nov 2019 at 10:43, Geertjan Wielenga wrote: > Can someone -- preferably Eric, Neil, Laszlo, Jan, or Matthias, suggest a > way forward to get an update out, i.e., we could even call it 11.2.1, > maybe, if we can't figure out how to release the two modules (what would be > the problem with doing it as Laszlo did for Gradle)? We can't do it as Laszlo did for Gradle because of changes in the build system. And in many respects this should be simpler. We need to * merge the relevant PRs to master and test. (perhaps provide nbms via temporary UC?) * (ideally) cherry pick locally and open new PRs on top of release112 (better than pushing to release branch IMO because of Travis, etc.) * Merge to release branch. * write the hash into the release JSON file (probably 11.2-patch1) and trigger a build. * ***somehow*** sign the relevant nbms. * vote on source zip and required nbms. There is one more potential PR for the patch update. They all have Cherry Pick labels on them. https://github.com/apache/netbeans/pulls?q=is%3Apr+is%3Aopen+label%3A%22Cherry+Pick%22 I'm happy to RM the process from point 3, but I'd rather the current PR authors handled steps 1 and 2. If I do, add me as a reviewer on the step 2 PR when they're ready. And we still need an answer for the signing part for 11.2 updates - perhaps the web signing via Apache is the way, but I'll need to follow up with infra. Few suggestions for 11.3+ are great there but don't help us with this update. Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
Can someone -- preferably Eric, Neil, Laszlo, Jan, or Matthias, suggest a way forward to get an update out, i.e., we could even call it 11.2.1, maybe, if we can't figure out how to release the two modules (what would be the problem with doing it as Laszlo did for Gradle)? Gj On Thu, Nov 7, 2019 at 11:05 AM Geertjan Wielenga wrote: > There appear to be two issues that would be best to make available as > updates as soon as we can -- relating to nb-javac and HTML parsing. > > What would be the problem with voting on the sources of those two modules > and then making them available via the plugin portal? > > Gj > > On Mon, Nov 4, 2019 at 6:54 PM Eric Barboni wrote: > >> Hi, >> Not sure what the needs exactly. >> But If you rebuild a patched NetBeans with a forced version >> RELEASE112-update1. You can pick the patched nbm you want. And alter pom to >> put RELEASE112 for dep (you know are were not modified). >> >> Then vote with sources + the limited artefacts RELEASE112-update1 to be >> able to release them in central >> >> Best Regards >> Eric >> >> >> >> >> -Message d'origine----- >> De : Neil C Smith >> Envoyé : mardi 29 octobre 2019 18:42 >> À : dev >> Objet : Re: [DISCUSS] Handling release updates >> >> On Tue, 29 Oct 2019 at 15:53, Eric Barboni wrote: >> > You cannot do a RELEASE112.1 in the >> org.netbeans(api,modules,clusters,external) without rebuild the whole >> NetBeans stack because every pom will need the RELEASE112.1 version on >> dependencies nbm being a side artefacts. >> > It's not possible to overwrite a released artefacts you cannot do a >> RELEASE112 again. >> >> Yes, I know artefacts can't be overwritten, so thought as much. Kind of >> makes it even harder to push a patch release for Maven modules. >> Would be good if that was not the case, but I guess it's not a short term >> (ie. 11.2 update) mechanism. And Maven probably won't get nb-javac module >> fix, although that's probably not that much of an issue. >> >> Still think it worth considering longer term. Means only one set of NBMs >> need signing and maintaining, and may remove some issues around using >> Apache mirrors for the UCs. How feasible is changing the modules to use >> spec version and RELEASE11X just for overarching POM files? >> >> Best wishes, >> >> Neil >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org >> For additional commands, e-mail: dev-h...@netbeans.apache.org >> >> For further information about the NetBeans mailing lists, visit: >> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists >> >> >> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org >> For additional commands, e-mail: dev-h...@netbeans.apache.org >> >> For further information about the NetBeans mailing lists, visit: >> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists >> >> >> >>
Re: [DISCUSS] Handling release updates
There appear to be two issues that would be best to make available as updates as soon as we can -- relating to nb-javac and HTML parsing. What would be the problem with voting on the sources of those two modules and then making them available via the plugin portal? Gj On Mon, Nov 4, 2019 at 6:54 PM Eric Barboni wrote: > Hi, > Not sure what the needs exactly. > But If you rebuild a patched NetBeans with a forced version > RELEASE112-update1. You can pick the patched nbm you want. And alter pom to > put RELEASE112 for dep (you know are were not modified). > > Then vote with sources + the limited artefacts RELEASE112-update1 to be > able to release them in central > > Best Regards > Eric > > > > > -Message d'origine- > De : Neil C Smith > Envoyé : mardi 29 octobre 2019 18:42 > À : dev > Objet : Re: [DISCUSS] Handling release updates > > On Tue, 29 Oct 2019 at 15:53, Eric Barboni wrote: > > You cannot do a RELEASE112.1 in the > org.netbeans(api,modules,clusters,external) without rebuild the whole > NetBeans stack because every pom will need the RELEASE112.1 version on > dependencies nbm being a side artefacts. > > It's not possible to overwrite a released artefacts you cannot do a > RELEASE112 again. > > Yes, I know artefacts can't be overwritten, so thought as much. Kind of > makes it even harder to push a patch release for Maven modules. > Would be good if that was not the case, but I guess it's not a short term > (ie. 11.2 update) mechanism. And Maven probably won't get nb-javac module > fix, although that's probably not that much of an issue. > > Still think it worth considering longer term. Means only one set of NBMs > need signing and maintaining, and may remove some issues around using > Apache mirrors for the UCs. How feasible is changing the modules to use > spec version and RELEASE11X just for overarching POM files? > > Best wishes, > > Neil > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
RE: [DISCUSS] Handling release updates
Hi, Not sure what the needs exactly. But If you rebuild a patched NetBeans with a forced version RELEASE112-update1. You can pick the patched nbm you want. And alter pom to put RELEASE112 for dep (you know are were not modified). Then vote with sources + the limited artefacts RELEASE112-update1 to be able to release them in central Best Regards Eric -Message d'origine- De : Neil C Smith Envoyé : mardi 29 octobre 2019 18:42 À : dev Objet : Re: [DISCUSS] Handling release updates On Tue, 29 Oct 2019 at 15:53, Eric Barboni wrote: > You cannot do a RELEASE112.1 in the > org.netbeans(api,modules,clusters,external) without rebuild the whole > NetBeans stack because every pom will need the RELEASE112.1 version on > dependencies nbm being a side artefacts. > It's not possible to overwrite a released artefacts you cannot do a > RELEASE112 again. Yes, I know artefacts can't be overwritten, so thought as much. Kind of makes it even harder to push a patch release for Maven modules. Would be good if that was not the case, but I guess it's not a short term (ie. 11.2 update) mechanism. And Maven probably won't get nb-javac module fix, although that's probably not that much of an issue. Still think it worth considering longer term. Means only one set of NBMs need signing and maintaining, and may remove some issues around using Apache mirrors for the UCs. How feasible is changing the modules to use spec version and RELEASE11X just for overarching POM files? Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
On Tue, 29 Oct 2019 at 15:53, Eric Barboni wrote: > You cannot do a RELEASE112.1 in the > org.netbeans(api,modules,clusters,external) without rebuild the whole > NetBeans stack because every pom will need the RELEASE112.1 version on > dependencies nbm being a side artefacts. > It's not possible to overwrite a released artefacts you cannot do a > RELEASE112 again. Yes, I know artefacts can't be overwritten, so thought as much. Kind of makes it even harder to push a patch release for Maven modules. Would be good if that was not the case, but I guess it's not a short term (ie. 11.2 update) mechanism. And Maven probably won't get nb-javac module fix, although that's probably not that much of an issue. Still think it worth considering longer term. Means only one set of NBMs need signing and maintaining, and may remove some issues around using Apache mirrors for the UCs. How feasible is changing the modules to use spec version and RELEASE11X just for overarching POM files? Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
RE: [DISCUSS] Handling release updates
Sorry did not get this part, It's possible to generate catalog to link to maven central (will need some works to be sure to get all info maybe). It's a public repo. Nbm file are the same as the one in official release. Not sure following are pro/cons, just "idea" based on current status of tools (nb-repository-plugin) for the patch case if needed You cannot do a RELEASE112.1 in the org.netbeans(api,modules,clusters,external) without rebuild the whole NetBeans stack because every pom will need the RELEASE112.1 version on dependencies nbm being a side artefacts. It's not possible to overwrite a released artefacts you cannot do a RELEASE112 again. Hope It helps, Best regards Eric -Message d'origine- De : Neil C Smith Envoyé : samedi 26 octobre 2019 20:20 À : dev Objet : Re: [DISCUSS] Handling release updates On Sat, 26 Oct 2019 at 05:17, Laszlo Kishalmi wrote: > You put tremendous effort in the new pipeline to work Credit where credit is due, the bulk of that effort was Eric. Now thinking about it, one reason for the new build system is Maven artefacts. Which, include the NBMs as is as far as I know? And will need to have the same updates that we ship to the IDE. So, Eric / anyone - could we generate a distribution catalog.xml that uses Maven hosted nbms instead of the mirrors? The catalog itself could remain hosted on the VM where it is now. What pros / cons? > Let's listen for other ideas as well... Yes, agreed! Sorry, wasn't aiming to stop discussion, just pointing out that splitting distribution UCs would involve more changes than just adding it in - e.g the new build system and the RCP build harness would probably need rethinking to support multiple sources. One other infrastructure problem we have is that the catalog.xml links are relative, which means every module downloaded goes through the same redirects. Works for odd module updates, but seems to get refused with too many requests - try using the above mentioned RCP harness download, or installing an entire cluster, and it will probably fail. One other thing that would be good to solve in this discussion - ideally only the catalog itself needs to be done via .htaccess. Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
Hi, Am Montag, den 28.10.2019, 19:24 + schrieb Neil C Smith: > On Mon, 28 Oct 2019 at 19:00, Matthias Bläsing > wrote: > > if I'm not mistaken, currently the NBMs we produce are not signed when > > we release. This is what I suggest: > > No, they're not. I just remembered, where I saw this in the build: nb/updatecenters/build.xml there a new signing key is created, the nbms for javafx and nbjavac are build and signed with that key. Then the public key/certificate is embedded in the build as ide.ks. ide.ks is provided by org.netbeans.modules.updatecenters.resources.NetBeansKeyStoreProvider to the update center to be used to check the signatures embedded in the NBMs (see the META-INF directory of the javafx/nbjavac nbms to see the signature). That way the NBMs are fully trusted by the IDE and don't even trigger the Validation dialog (so far my reading of the update center gui). My idea would add a trusted certificate to ide.ks, that corresponds with a signing key, that only PMC members have access to. > > - all updates will be signed with that key, as it is trusted, it can be > > used to safely install updates > > How, or actually, where? That would still be a manual, local, job? > It would be great if we could sign during the Jenkins build. Or does > that just open another can of worms? Yes my idea would be to require the release manager to get the signing key from the SVN, decrypt it with his/her GPG key, use it to sign the update-center nbms and the remove the signing key again. > The other option that comes to mind - Jan mentioned validating the GPG > signatures - but would it be possible to just get the IDE to use our > KEYS file as a source for validation? Then you need to artifacts: The NBM and its corresponding detached signature. I agree, that it is possible to verify the signature that way, but how to get them combined? And we would still need to push an update to the current install base. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
On Mon, 28 Oct 2019 at 19:00, Matthias Bläsing wrote: > if I'm not mistaken, currently the NBMs we produce are not signed when > we release. This is what I suggest: No, they're not. > - all updates will be signed with that key, as it is trusted, it can be > used to safely install updates How, or actually, where? That would still be a manual, local, job? It would be great if we could sign during the Jenkins build. Or does that just open another can of worms? The other option that comes to mind - Jan mentioned validating the GPG signatures - but would it be possible to just get the IDE to use our KEYS file as a source for validation? Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
Hi, Am Sonntag, den 27.10.2019, 12:18 +0100 schrieb Jan Lahoda: > [How to handle updates] > But I have no idea if we asked to an access there. (And if ASF would pay > for each signed file, then singing several hundreds NBMs would not fly > anyway, I think.) But we could at least use that for this update release > (which will likely only consist of a handful of NBMs), and try to do > something better for the future. if I'm not mistaken, currently the NBMs we produce are not signed when we release. This is what I suggest: - lets create a signing key for the netbeans releases, place the private key on the PMC SVN directory, as is done with the SSH key to access the ousol binaries site - add the public key for the signing key as a trusted code signing certificate to the netbeans distribution - all updates will be signed with that key, as it is trusted, it can be used to safely install updates - we should make sure, that we can handle multiple trusted keys, that way we can push a new key, using an existing key This still requires once a manual installation of the first netbeans version, that carries the key. What do you think? Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
On Mon, 28 Oct 2019 at 18:16, Geertjan Wielenga wrote: > How are we doing in this discussion, at least, what can we do to release > the fix to the nb-javac which, without it, will otherwise cause refactoring > to fail if nb-javac is installed? We need it merged to master. We ideally need a temporary UC where people can check it works OK with NB 11.2. We need a cherry-picked PR for release112. We need to vote on a new source zip (along with any other fixes we want to include in a patch release). We need to upload changed nbms and edit the catalog. All that is mostly, OK. At some point in that we really need to figure out how to sign the updated NBMs though. Also interested in Eric's view on using Maven for updates, because this might be a better place to link the new NBMs from? Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
Hi all, How are we doing in this discussion, at least, what can we do to release the fix to the nb-javac which, without it, will otherwise cause refactoring to fail if nb-javac is installed? Gj On Sun, Oct 27, 2019 at 12:19 PM Jan Lahoda wrote: > On Fri, Oct 25, 2019 at 1:04 PM Neil C Smith > wrote: > > > On Thu, 24 Oct 2019 at 21:17, Jan Lahoda wrote: > > >> Still unsure about how we handle catalog and signing issues though. > > >> Am I right in thinking with current situation people will see a > > >> warning on update? Definitely see this already when re-enabling > > >> nb-javac. > > > > > > That is one of the things I'd like to try. The update will be a two > > phase process - first update the nb/updatecenters module, and then > > nb-javac. I *think* there should be no warning for the second update > > (because the NBM is signed using the key that is embedded in the > > updatecenters module), but I am less sure about how exactly the first > > update will work. > > > > I'm fairly sure the first update at least will show a warning. > > Installing other nbms from the distribution UC does now. > > > > Yes, i am afraid so, unless we find a way to sensibly sign the NBMs. > > There is this (which is probably what Reema shared): > https://blogs.apache.org/infra/entry/code_signing_service_now_available > > But I have no idea if we asked to an access there. (And if ASF would pay > for each signed file, then singing several hundreds NBMs would not fly > anyway, I think.) But we could at least use that for this update release > (which will likely only consist of a handful of NBMs), and try to do > something better for the future. > > But the second update should be without warning, if the NBMs is done > properly. > > > > Check the link Reema shared that I posted earlier. We might be able > > to use that, in the short term manually signing the relevant updates > > via the web interface? Except that shows a browser security error for > > me. And also specifies .jar extension. > > > > What other options are there? Is there any *secure* way that we can > > add trust in the IDE for modules built on ASF infrastructure? If I > > understand it correctly, the current way the third-party UC does this > > will only work for a single build? > > > > I wonder if we could validate the GPG signatures (.asc) we need to use > anyway - the IDE could then have a list of "trusted" KEYs. > > Jan > > > > Best wishes, > > > > Neil > > >
Re: [DISCUSS] Handling release updates
On Fri, Oct 25, 2019 at 1:04 PM Neil C Smith wrote: > On Thu, 24 Oct 2019 at 21:17, Jan Lahoda wrote: > >> Still unsure about how we handle catalog and signing issues though. > >> Am I right in thinking with current situation people will see a > >> warning on update? Definitely see this already when re-enabling > >> nb-javac. > > > > That is one of the things I'd like to try. The update will be a two > phase process - first update the nb/updatecenters module, and then > nb-javac. I *think* there should be no warning for the second update > (because the NBM is signed using the key that is embedded in the > updatecenters module), but I am less sure about how exactly the first > update will work. > > I'm fairly sure the first update at least will show a warning. > Installing other nbms from the distribution UC does now. > Yes, i am afraid so, unless we find a way to sensibly sign the NBMs. There is this (which is probably what Reema shared): https://blogs.apache.org/infra/entry/code_signing_service_now_available But I have no idea if we asked to an access there. (And if ASF would pay for each signed file, then singing several hundreds NBMs would not fly anyway, I think.) But we could at least use that for this update release (which will likely only consist of a handful of NBMs), and try to do something better for the future. But the second update should be without warning, if the NBMs is done properly. > Check the link Reema shared that I posted earlier. We might be able > to use that, in the short term manually signing the relevant updates > via the web interface? Except that shows a browser security error for > me. And also specifies .jar extension. > > What other options are there? Is there any *secure* way that we can > add trust in the IDE for modules built on ASF infrastructure? If I > understand it correctly, the current way the third-party UC does this > will only work for a single build? > I wonder if we could validate the GPG signatures (.asc) we need to use anyway - the IDE could then have a list of "trusted" KEYs. Jan > Best wishes, > > Neil >
Re: [DISCUSS] Handling release updates
On Sat, 26 Oct 2019 at 05:17, Laszlo Kishalmi wrote: > You put tremendous effort in the new pipeline to work Credit where credit is due, the bulk of that effort was Eric. Now thinking about it, one reason for the new build system is Maven artefacts. Which, include the NBMs as is as far as I know? And will need to have the same updates that we ship to the IDE. So, Eric / anyone - could we generate a distribution catalog.xml that uses Maven hosted nbms instead of the mirrors? The catalog itself could remain hosted on the VM where it is now. What pros / cons? > Let's listen for other ideas as well... Yes, agreed! Sorry, wasn't aiming to stop discussion, just pointing out that splitting distribution UCs would involve more changes than just adding it in - e.g the new build system and the RCP build harness would probably need rethinking to support multiple sources. One other infrastructure problem we have is that the catalog.xml links are relative, which means every module downloaded goes through the same redirects. Works for odd module updates, but seems to get refused with too many requests - try using the above mentioned RCP harness download, or installing an entire cluster, and it will probably fail. One other thing that would be good to solve in this discussion - ideally only the catalog itself needs to be done via .htaccess. Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
On 10/25/19 8:55 AM, Neil C Smith wrote: On Fri, 25 Oct 2019 at 16:02, Laszlo Kishalmi wrote: So anyone can step up coordinate and do a patch release of some modules if the community approves that. When we are releasing the whole IDE the RM has one orientation: the whole IDE. I'm -1 to voting on patch sources vs a whole IDE patch release (even if +1 to anyone else RM'ing it! ;-) ). I think the way that the patch release was done previously would be difficult to achieve with the new build system. We need to ensure that even patch releases end up with consistent build numbers / git hash info. I also think the patch voting was more complicated for voters, and "awkward" from an Apache compatibility point of view. Hence suggesting we still do a vote on the full sources built on netbeans-TLP, but only nominate required binaries. Well, I'm not pushing for the partial source release/vote. You put tremendous effort in the new pipeline to work, I very much believe that it is easier, more reliable and safer to vote on the whole source and nominate the required binaries. On Fri, 25 Oct 2019 at 14:01, Laszlo Kishalmi wrote: Probably the ugliest part was the actual release of the nbms. In the future we could create a separate update center for release updates and ship that configured in the release. I think the new plugin portal infrastructure probably could help, if that'd support multi tenancy. Good point on the ugly part! Although again I'd vote -1 on splitting the UC for the distribution in two. Mainly from a downstream distribution / derivative perspective - enlightened self interest at play there! :-) However, we do serve the catalog from the VM, and the catalog can have absolute rather than relative links, meaning we don't need to serve the updated artefacts themselves the same way. Still, the other thing we need to keep in mind is that we may be starting to ship installers that can install specific clusters. One way of upgrading such a release later is to install another cluster via UC? Not having them signed / having multiple centres may also be a problem there. I'm not sure I get this, but I think that would be explained in more detail. Let's listen for other ideas as well... Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
On Fri, 25 Oct 2019 at 16:02, Laszlo Kishalmi wrote: > So anyone can step up coordinate and do a patch release of some modules > if the community approves that. When we are releasing the whole IDE the > RM has one orientation: the whole IDE. I'm -1 to voting on patch sources vs a whole IDE patch release (even if +1 to anyone else RM'ing it! ;-) ). I think the way that the patch release was done previously would be difficult to achieve with the new build system. We need to ensure that even patch releases end up with consistent build numbers / git hash info. I also think the patch voting was more complicated for voters, and "awkward" from an Apache compatibility point of view. Hence suggesting we still do a vote on the full sources built on netbeans-TLP, but only nominate required binaries. On Fri, 25 Oct 2019 at 14:01, Laszlo Kishalmi wrote: > Probably the ugliest part was the actual release of the nbms. In the > future we could create a separate update center for release updates and > ship that configured in the release. I think the new plugin portal > infrastructure probably could help, if that'd support multi tenancy. Good point on the ugly part! Although again I'd vote -1 on splitting the UC for the distribution in two. Mainly from a downstream distribution / derivative perspective - enlightened self interest at play there! :-) However, we do serve the catalog from the VM, and the catalog can have absolute rather than relative links, meaning we don't need to serve the updated artefacts themselves the same way. Still, the other thing we need to keep in mind is that we may be starting to ship installers that can install specific clusters. One way of upgrading such a release later is to install another cluster via UC? Not having them signed / having multiple centres may also be a problem there. Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
On 10/25/19 7:17 AM, Eric Barboni wrote: Hi, Needs to be simple and formal enough to be Apache compatible. I'm afraid that if it's too complicated, a RM can cancel release vote because if it may look simpler to merge some fix and revote. Or let the bug until the next X.Y release. And if a RM is more java oriented he may not see c++ or web issue as important to deserve an update. (kind if Laszlo were not RM at the time maybe gradle patch would have never been set) Well that's not entirely true. Each release has it's own RM 11.1 and 11.2 happens to be Neil. A patch release can have a different RM. What for example you are doing with the Maven Archetypes (btw thank you for carry on that) are RM. It is the scope of such releases are way smaller than releasing the whole IDE. I would have created the Gradle patch release even if I was not the RM for the whole IDE that time, though having two releases behind my back certainly helped to have the confidence to walk though the path. So anyone can step up coordinate and do a patch release of some modules if the community approves that. When we are releasing the whole IDE the RM has one orientation: the whole IDE. Regards Eric -Message d'origine- De : Laszlo Kishalmi Envoyé : vendredi 25 octobre 2019 14:52 À : dev@netbeans.apache.org Objet : Re: [DISCUSS] Handling release updates Well, the Gradle patch has been made in the following way: 1. The result of the release build has been further processed, extracting the source files for the changed modules and the necessary files like NOTICE and licenses. 2. So the output of the patch build was a small source zip and the corresponding nbm-s as binary. The README had the instruction that how you need to paths the existing source bundle with the new one to create the binaries. 3. We voted on the source files only 4. The nbms were overwritten in the distribution directory and the updates.xml.gz was patched by hand. Probably the ugliest part was the actual release of the nbms. In the future we could create a separate update center for release updates and ship that configured in the release. I think the new plugin portal infrastructure probably could help, if that'd support multi tenancy. On 10/23/19 5:51 AM, Neil C Smith wrote: On Wed, 23 Oct 2019 at 13:47, Geertjan Wielenga wrote: Will we really need to go through a vote process for this change? IMO, yes - it's still a source change. And that's not quite the only change required. But there are other things we might want to make patches for too. This thread was not meant to be specific to that one particular issue. We need to work out a process for how we do this in future. Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
Well, the Gradle patch has been made in the following way: 1. The result of the release build has been further processed, extracting the source files for the changed modules and the necessary files like NOTICE and licenses. 2. So the output of the patch build was a small source zip and the corresponding nbm-s as binary. The README had the instruction that how you need to paths the existing source bundle with the new one to create the binaries. 3. We voted on the source files only 4. The nbms were overwritten in the distribution directory and the updates.xml.gz was patched by hand. Probably the ugliest part was the actual release of the nbms. In the future we could create a separate update center for release updates and ship that configured in the release. I think the new plugin portal infrastructure probably could help, if that'd support multi tenancy. On 10/23/19 5:51 AM, Neil C Smith wrote: On Wed, 23 Oct 2019 at 13:47, Geertjan Wielenga wrote: Will we really need to go through a vote process for this change? IMO, yes - it's still a source change. And that's not quite the only change required. But there are other things we might want to make patches for too. This thread was not meant to be specific to that one particular issue. We need to work out a process for how we do this in future. Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
On Thu, 24 Oct 2019 at 21:17, Jan Lahoda wrote: >> Still unsure about how we handle catalog and signing issues though. >> Am I right in thinking with current situation people will see a >> warning on update? Definitely see this already when re-enabling >> nb-javac. > > That is one of the things I'd like to try. The update will be a two phase > process - first update the nb/updatecenters module, and then nb-javac. I > *think* there should be no warning for the second update (because the NBM is > signed using the key that is embedded in the updatecenters module), but I am > less sure about how exactly the first update will work. I'm fairly sure the first update at least will show a warning. Installing other nbms from the distribution UC does now. Check the link Reema shared that I posted earlier. We might be able to use that, in the short term manually signing the relevant updates via the web interface? Except that shows a browser security error for me. And also specifies .jar extension. What other options are there? Is there any *secure* way that we can add trust in the IDE for modules built on ASF infrastructure? If I understand it correctly, the current way the third-party UC does this will only work for a single build? Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
On Thu, Oct 24, 2019 at 11:07 AM Neil C Smith wrote: > On Thu, 24 Oct 2019 at 09:48, Jan Lahoda wrote: > > Releasing the full source does sound easier for processes, so if > reviewers are ok with that, sounds good to me. Should be possible to only > upload specific NBMs. I guess the question is when we do the update, given > the refactoring is broken for 9+. > > I'm thinking maybe ~2 weeks? Given there is a workaround > (uninstalling nb-javac) and the potential for other things that have > been mentioned to maybe require fixes, we could aim for a patch > release then? > > In the meantime, could we also provide an additional update centre for > nb-javac so that people who want to can install and test the fixed > version? And is the fixed version ready yet anyway? > Should be this, I believe: https://github.com/apache/netbeans/pull/1589 I would like to try myself, to check that things are working, but didn't get to that. > Still unsure about how we handle catalog and signing issues though. > Am I right in thinking with current situation people will see a > warning on update? Definitely see this already when re-enabling > nb-javac. > That is one of the things I'd like to try. The update will be a two phase process - first update the nb/updatecenters module, and then nb-javac. I *think* there should be no warning for the second update (because the NBM is signed using the key that is embedded in the updatecenters module), but I am less sure about how exactly the first update will work. Jan > How do we address that? Can we add anything in to our existing build > process within that timeframe? > > Best wishes, > > Neil > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
Re: [DISCUSS] Handling release updates
On Thu, 24 Oct 2019 at 09:48, Jan Lahoda wrote: > Releasing the full source does sound easier for processes, so if reviewers > are ok with that, sounds good to me. Should be possible to only upload > specific NBMs. I guess the question is when we do the update, given the > refactoring is broken for 9+. I'm thinking maybe ~2 weeks? Given there is a workaround (uninstalling nb-javac) and the potential for other things that have been mentioned to maybe require fixes, we could aim for a patch release then? In the meantime, could we also provide an additional update centre for nb-javac so that people who want to can install and test the fixed version? And is the fixed version ready yet anyway? Still unsure about how we handle catalog and signing issues though. Am I right in thinking with current situation people will see a warning on update? Definitely see this already when re-enabling nb-javac. How do we address that? Can we add anything in to our existing build process within that timeframe? Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
Releasing the full source does sound easier for processes, so if reviewers are ok with that, sounds good to me. Should be possible to only upload specific NBMs. I guess the question is when we do the update, given the refactoring is broken for 9+. Jan 23. října 2019 15:03:03 SELČ, Neil C Smith napsal: >On Wed, 23 Oct 2019 at 13:55, Geertjan Wielenga >wrote: >> >> Agree completely. I suggest you put your proposal in a lazy consensus >> thread. > >It's a best a half-baked proposal! :-) I was hoping for some input >and discussion first to clarify what we need and how best to achieve. > >Best wishes, > >Neil > >- >To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org >For additional commands, e-mail: dev-h...@netbeans.apache.org > >For further information about the NetBeans mailing lists, visit: >https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists -- Odesláno aplikací K-9 Mail ze systému Android. Omluvte prosím moji stručnost.
Re: [DISCUSS] Handling release updates
On Wed, 23 Oct 2019 at 14:40, Eric Barboni wrote: > > What are the distribution nbms ? I see nbms in dist but they have all an > asc file associated. Yes, those. They have .asc files. But that's not the same as NBM / JAR signing. eg. link Reema shared when this was last discussed - https://reference.apache.org/pmc/codesigning Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
RE: [DISCUSS] Handling release updates
What are the distribution nbms ? I see nbms in dist but they have all an asc file associated. Regards Eric -Message d'origine- De : Neil C Smith Envoyé : mercredi 23 octobre 2019 13:19 À : dev Objet : Re: [DISCUSS] Handling release updates On Tue, 22 Oct 2019 at 11:13, Neil C Smith wrote: > I'm wondering whether if we do ship updates, we trigger a new > milestone in the release branch, and have a vote on full sources, as > per normal. Alongside that we nominate specific module convenience > binaries (nbms) to be added to the mirrors / update centre. Two further thoughts on that - * we would either need to merge the catalog info to include the new modules OR we remove the 11.2/nbms folder completely and link to 11.2-update1/nbms ? Second way simpler, but we end up with new build versions of all modules. * currently the distribution nbms aren't signed as far as I know?! What are the implications for updates there? Some thoughts here would be good! How do we best handle this at ASF? Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
On Wed, 23 Oct 2019 at 13:55, Geertjan Wielenga wrote: > > Agree completely. I suggest you put your proposal in a lazy consensus > thread. It's a best a half-baked proposal! :-) I was hoping for some input and discussion first to clarify what we need and how best to achieve. Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Handling release updates
Agree completely. I suggest you put your proposal in a lazy consensus thread. Gj On Wed, Oct 23, 2019 at 2:52 PM Neil C Smith wrote: > On Wed, 23 Oct 2019 at 13:47, Geertjan Wielenga > wrote: > > Will we really need to go through a vote process for this change? > > IMO, yes - it's still a source change. And that's not quite the only > change required. > > But there are other things we might want to make patches for too. > This thread was not meant to be specific to that one particular issue. > We need to work out a process for how we do this in future. > > Best wishes, > > Neil > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
Re: [DISCUSS] Handling release updates
The question is though, just for clarity, whether we really do need to vote at all if (when) we provide a patch soon after the 11.2 release for a fix to nb-javac, which will mean that only this specific file will need to change: https://github.com/apache/netbeans/blob/master/nb/updatecenters/extras/nbjavac.impl/release/modules/ext/nb-javac-13-impl.jar.external I.e., the URL and fallback URL and hash will need to change in that module and nothing else. Will we really need to go through a vote process for this change? Gj On Wed, Oct 23, 2019 at 1:19 PM Neil C Smith wrote: > On Tue, 22 Oct 2019 at 11:13, Neil C Smith wrote: > > I'm wondering whether if we do ship updates, we trigger a new > > milestone in the release branch, and have a vote on full sources, as > > per normal. Alongside that we nominate specific module convenience > > binaries (nbms) to be added to the mirrors / update centre. > > Two further thoughts on that - > > * we would either need to merge the catalog info to include the new > modules OR we remove the 11.2/nbms folder completely and link to > 11.2-update1/nbms ? Second way simpler, but we end up with new build > versions of all modules. > > * currently the distribution nbms aren't signed as far as I know?! What > are the implications for updates there? > > Some thoughts here would be good! How do we best handle this at ASF? > > Best wishes, > > Neil > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
Re: [DISCUSS] Handling release updates
On Tue, 22 Oct 2019 at 11:13, Neil C Smith wrote: > I'm wondering whether if we do ship updates, we trigger a new > milestone in the release branch, and have a vote on full sources, as > per normal. Alongside that we nominate specific module convenience > binaries (nbms) to be added to the mirrors / update centre. Two further thoughts on that - * we would either need to merge the catalog info to include the new modules OR we remove the 11.2/nbms folder completely and link to 11.2-update1/nbms ? Second way simpler, but we end up with new build versions of all modules. * currently the distribution nbms aren't signed as far as I know?! What are the implications for updates there? Some thoughts here would be good! How do we best handle this at ASF? Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists