support/1.13 was cut on May 4, 2020 as per Geode's published time-based schedule [1] (Monday on or after Feb 1, May 1, Aug 1, Nov 1)
prior to the expected Aug 3 date to cut support/1.14, the Geode community decided in July [2] that the usual quarterly schedule would not apply to 1.14, and then clarified in this thread that stabilization would instead happen on develop in parallel with drawing down the number of issues on the 1.14 dashboard [3]. I still see 7 issues on the dashboard. I had optimistically hoped it would work out to cut the branch today Feb 1 (in furtherance of returning to our quarterly schedule), but it doesn't seem like we're ready? Hopefully this isn't a case of the "slippery slope" Geode was trying to avoid [4] by adopted a time-based cadence in 2018. [1] https://www.cwiki.us/display/GEODE/Releasing+Apache+Geode#ReleasingApacheGeode-Announceintenttobranch [2] https://lists.apache.org/x/thread.html/ra8ef649c2d02a216f42152d8b468f03e14bed0c0dccea6a0a9b511db@%3Cdev.geode.apache.org%3E [3] https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12336052 [4] https://lists.apache.org/x/thread.html/d36a63c3794d13506ecad3d52a2aca938dcf0f8509b61860bbbc50cd@%3Cdev.geode.apache.org%3E On 1/6/21, 10:18 AM, "Nabarun Nag" <n...@vmware.com> wrote: Added a couple of tickets with the blocker label and are now available on the dashboard. Please feel free to pick up those tasks. Do reach out if anyone needs more information. Regards Nabarun ________________________________ From: Alexander Murmann <amurm...@vmware.com> Sent: Wednesday, January 6, 2021 7:39 AM To: dev@geode.apache.org <dev@geode.apache.org> Subject: Re: [DISCUSS] Geode 1.14 Hi team! If I am reading the silence correctly as silent approval, can everyone please start to add the blocks-1.14.0 label to all tickets we should consider as release blockers? I also would encourage us to not remove the label when we resolve a ticket. This allows us to get a better understanding of our progress. We should remove the label if we decide that we can ship without a fix. On a practical note: It seems like the dashboard doesn't always show all ticket changes immediately. I'll let you know when I get a better understanding of that behavior. ________________________________ From: Alexander Murmann <amurm...@vmware.com> Sent: Tuesday, January 5, 2021 08:34 To: dev@geode.apache.org <dev@geode.apache.org> Subject: Re: [DISCUSS] Geode 1.14 I agree with Jianxia that a dashboard would be helpful. Not every bug that affects a release should necessarily be a release blocker. Factors like low severity, existence in prior versions and time to fix might all play a role in deciding that a bug should be fixed in a later version. So we need a way to track what issues are considered a release blocker separately from what versions are affected. Ideally we'd use something like a blocked-releases fields. We don't have that right now, so I propose we use a blocks-1.14.0 label. I started on a dashboard that tracks these here<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fsecure%2FDashboard.jspa%3FselectPageId%3D12336052&data=04%7C01%7Conichols%40vmware.com%7C49e9e3e3abd4491e31c308d8b26f6a91%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637455538898345614%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=o3ACOtwbpw%2Fvg4Ek2c1AqRFacai3UQhGQo94he1VQ0o%3D&reserved=0>. Everyone should have access to view it. The dashboard shows all issues with the label. There are two lists one with open issues and one with resolved issues. I propose that we keep the blocker label on an issue if we resolve the issue, but remove it if we decide against resolving it in this version. In that case we might want to consider already tagging it with a future version (e.g. blocks-1.14.1), so that it stays top of mind. We should only do that though if we indeed want to fix it in that version.? Once the list of open issues marked as blockers is down to a handful, we should revisit the discussion about cutting the release branch. If we agree that this is the right approach, I'll need all of your help in going back to open tickets and labeling them as release blockers where appropriate. How does that sound? ________________________________ From: Jacob Barrett <jabarr...@vmware.com> Sent: Monday, January 4, 2021 16:40 To: dev@geode.apache.org <dev@geode.apache.org> Subject: Re: [DISCUSS] Geode 1.14 > On Jan 4, 2021, at 3:42 PM, Owen Nichols <onich...@vmware.com> wrote: > > How to tell whether develop is stable? Same way we tell if a release branch is stable. Listen, cutting a release branch from the develop branch shouldn’t result in weeks worth of stabilization of the release branch. That is a smell that we have bad things going into develop. If there are bad things in develop then we are introducing new things to develop on top of bad things, which will just end up being more bad things. It isn’t cut or dry. I am not saying release from develop on an arbitrary day. I am saying we know develop isn’t stable. We know a release branch will take weeks to repair. Lets turn that around, lets make develop stable so a release branch takes days to release, not weeks. Yes there will be issues found on a release branch that have to be fixed but that should be an exception, not the norm. -Jake
