Thanks for putting together this script, Dan. It's always humbling to discover ways that a user's environment can differ from the tightly-controlled conditions of CI.
I've noticed we've shipped quite a few releases recently with the bare minimum of votes. I hope this will encourage more participation from Geode's 54 PMC members [1]. Even if you are not a PMC member you can still run some checks and offer an "advisory" vote on the release candidate. "Ad-hoc" testing is still valuable too. Whether you have a pet project or full-blown application that uses Geode (or want to start one [2]), real-world testing of Geode can also shake out things we never thought of. [1] https://projects.apache.org/committee.html?geode [2] https://start.spring.io On 2/4/22, 10:56 AM, "Dan Smith" <dasm...@vmware.com> wrote: Hi all, I'd like to suggest something that might make voting on releases a little clearer and easier. I feel like we've been a bit vague about what kind of testing PMC members are supposed to do on a release candidate, and I see different folks (including myself) running different kinds of ad hoc testing. I'd like to suggest that we should mostly focus on things that are either apache requirements for voting on releases or can't reasonably be testing in CI. The apache release policy [1] says "Before voting +1 PMC members are required to download the signed source code package, compile it as provided, and test the resulting executable on their own platform, along with also verifying that the package meets the requirements of the ASF policy on releases." I checked in a script that can do the building and signature verification for you [2]. My hope is that we can improve this script do to all of the testing that we think is important to do on a developers machine before VOTING +1, and free up more time to look at the commits, source files etc. and thinking about if this is what we should be releasing. I'm not trying to discourage any ad hoc testing someone feels like they want to do, but I do want to make sure that everyone is in agreement on what we should be doing before voting on a release and hopefully make it so that everyone feels comfortable voting without wondering what they are supposed to test. [1] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23approving-a-release&data=04%7C01%7Conichols%40vmware.com%7C7bec2e36664d45df10bb08d9e8100ee5%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637795977955611092%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=cslqHDG12fgy8kAwLvh1QDNoeRs9nZdnK9uz2QtckLY%3D&reserved=0 [2] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Fdevelop%2Fdev-tools%2Frelease-testing&data=04%7C01%7Conichols%40vmware.com%7C7bec2e36664d45df10bb08d9e8100ee5%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637795977955611092%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=qXqCZIivE1foYg%2F3q2jzUMxMEmIQwbVeRCxvE0M1O5A%3D&reserved=0 Thanks, -Dan
