All I know from this voting aspect is by following other project. On Apache Maven vote call contains, dist is only containing sources , binaries conveniences are on repository. Vote is handled on one thread.
On Apache Ant vote call contains, Dist tarball contains sources and binaries , Maven repository artefacts Snap Vote is handled on one thread. For Apache http server vote call They only vote on source on one thread. IT's explicitly written that binaries are not done by the project. Only by committer to the project. I think, if we want all our binaries to be endorsed by Apache NetBeans we need to vote on them. We may try concurrent: Release Manager only care on building source Then vote (72h) 3 binding +1 vote On the voted source, we build conveniences maven,binaries,installer,(eventually snap to be complete ) and for each a vote (72h) 9(+3) binding +1 vote required to have them all. We may try like Ant or Maven "Heavy" preparation and synchronization from people that may help preparing Maven,Snap,Installer , with Release Manager Get a bigger vote mail with all element prepared.(72h) 3 binding +1 vote required to have them all. Best Regards Eric -----Message d'origine----- De : Neil C Smith <[email protected]> Envoyé : jeudi 3 octobre 2019 12:43 À : dev <[email protected]> Objet : [DISCUSS] Handling convenience binary vote(?) for 11.2 Hi All, While waiting for some testing with beta2 ahead of announcing it, I wanted to follow up on the discussion [1] about approving convenience binaries. There was some talk of having a voting or lazy consensus thread on them, or linking them to the release vote. To date, we have only voted on source releases - binaries may have been ready at vote time, but in the voting template we've been explicitly telling everyone they're not relevant and not linking them in! So, what to do for NB 11.2? We could add the binaries into the release vote. That would require changing our voting template, and I think considering what steps might need doing in addition to the required steps for a binding release vote from [2] We could have concurrent voting or consensus threads on the binary artefacts, perhaps separate for installers, Maven, etc. If there is a problem with any one binary that doesn't require source changes to fix it, it then need not delay the release vote itself passing. Some binaries may come later. My preference is probably the second option (if we have to do either). Incidentally, in the original thread my preference was not to do either of these things so formally! At the same time, I did think some process so that another PMC member had given the once-over on any binary to check requirements had been met was useful. Neither of those options actually do that. Maybe there's merit to a consensus thread with associated wiki page table of binaries that PMC members can tick off when they've checked any one of them? We can know at a glance what has and hasn't been checked over. [1] - https://lists.apache.org/thread.html/c0d11a5d311bb4bdd73ee8488e0383ea2b04166c820be183b54f1182@%3Cdev.netbeans.apache.org%3E [2] - http://www.apache.org/legal/release-policy.html#approving-a-release Best wishes, Neil Volunteer Release Manager for Apache Netbeans 11.2 --------------------------------------------------------------------- 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 --------------------------------------------------------------------- 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
