...

1. Over the following week, review and merge any inbound fixes to delivery.
2. As soon as there is any change in delivery, open two pull requests to sync branches - Sync delivery to releaseXXX for XX-rcN (see example) and Sync delivery to master after XX-rcN (see example)
3. If there are no merged fixes and no open major / critical issues for this release, consider whether it's time to move to a vote. See also the criteria described at: Pull requests for delivery. The release voting candidate must be built off the same git hash as the last release candidate - edit the existing milestone in netbeansrelease.json. 
4. If / when ready to trigger another release candidate, check and merge the sync PR to releaseXXX. Add a milestone based on the git hash of the sync PR merge commit to netbeansrelease.json.
5. Repeat from step 1, making sure to merge the other sync PR to master after verifying and announcing the release candidate. Do not sync to master if there are problems with the release candidate build - fix in delivery and resync / rebuild.

Moving towards a release vote:

1. The release voting candidate must be built off the same git hash as the last release candidate - edit the existing milestone in netbeansrelease.json. 
2. Instead of adding another hash, change what was the last release candidate to have, with version "vote:1", etc, see https://github.com/apache/netbeans-jenkins-lib/blob/master/meta/netbeansrelease.json#L1074
3. Do the build again, this time, only selecting parameters 'installers' and 'vscode'. Release build should never be pushed to nightlies.

Preparing the Code Base and Jenkins TLP Job

...