Re: [DISCUSS] Testing and voting on release candidates
This is awesome! Now I am excited to try this on our next vote! 🙂 From: Dan Smith Sent: Friday, February 4, 2022 10:56 To: dev@geode.apache.org Subject: [DISCUSS] Testing and voting on release candidates 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%7Camurmann%40vmware.com%7Cdea600fb778049baf6ad08d9e8100fc6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637795977950286033%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=sDszGN3xR7feZE4SH3%2B4sBEA8OqV9B8PGKYxdkn5SDQ%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%7Camurmann%40vmware.com%7Cdea600fb778049baf6ad08d9e8100fc6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637795977950286033%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=oWwALsJY8003Vh7SofZYmVrD2n0%2FcXXWxQr6gjrum7w%3D&reserved=0 Thanks, -Dan
Re: [DISCUSS] Testing and voting on release candidates
Dan, very good initiative. It ensures the minimum testing when someone votes, removing the guess factor. Putting together a script that will cover the minimal expectation is good idea, keeps it easier to accomplish the task. -Anil. On 2/7/22, 7:00 AM, "Alexander Murmann" wrote: This is awesome! Now I am excited to try this on our next vote! 🙂 From: Dan Smith Sent: Friday, February 4, 2022 10:56 To: dev@geode.apache.org Subject: [DISCUSS] Testing and voting on release candidates 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%7Cagingade%40vmware.com%7C03a59800957f49588daa08d9ea4a8fce%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637798428232854958%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=rqQ1F%2F6wg914m5R8cpi2YMOmHZMMT85fcQzXVA3NCmI%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%7Cagingade%40vmware.com%7C03a59800957f49588daa08d9ea4a8fce%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637798428232854958%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=R%2Fbu4eoBy4vzWyvzF16%2FOVSa1XKETR6QfMQSzC8EBcc%3D&reserved=0 Thanks, -Dan
New RFC about Enhancements in Off-heap memory fragmentation visibility
Hi fellow devs, Here is an RFC on "Enhance Off-heap memory fragmentation visibility": https://cwiki.apache.org/confluence/display/GEODE/Enhance+Off-heap+memory+fragmentation+visibility Your review and comments are very welcome! Alberto
