[Discuss] Cutting Geode 1.14
Hi everyone, TL;DR: Let's discuss 1.14 once 1.13 is out. If we stick to our cadence of cutting a release every 3 months and shipping it 1 month later, 1.14 is due to be cut two weeks from today. However, we haven't shipped 1.13 yet and are still struggling with some issues. I suggest that we postpone cutting the 1.14 release till we've actually shipped 1.13. Once we've shipped 1.13, we should have another conversation about timing of 1.14. I know the 1.13 release has been taxing on many people in our community and we might want to consider giving ourselves a little bit of a gap between releases.
Re: [Discuss] Cutting Geode 1.14
Alternatively, why not abandon 1.13 and try again with 1.14? > On Jul 20, 2020, at 9:21 AM, Alexander Murmann wrote: > > Hi everyone, > > TL;DR: Let's discuss 1.14 once 1.13 is out. > > If we stick to our cadence of cutting a release every 3 months and shipping > it 1 month later, 1.14 is due to be cut two weeks from today. However, we > haven't shipped 1.13 yet and are still struggling with some issues. > > I suggest that we postpone cutting the 1.14 release till we've actually > shipped 1.13. Once we've shipped 1.13, we should have another conversation > about timing of 1.14. I know the 1.13 release has been taxing on many > people in our community and we might want to consider giving ourselves a > little bit of a gap between releases.
Re: [Discuss] Cutting Geode 1.14
Playing devil's advocate here, but I think the reason we would not like to move to 1.14 would be that we have a ton testing already in to quantify issues on 1.13 and 1.14 would be (a bit) of an unknown quantity. Further, the core issues that we are waiting on for 1.13 are presumable 1.14 issues as well. Thanks, Mark On 7/20/20, 9:39 AM, "Jacob Barrett" wrote: Alternatively, why not abandon 1.13 and try again with 1.14? > On Jul 20, 2020, at 9:21 AM, Alexander Murmann wrote: > > Hi everyone, > > TL;DR: Let's discuss 1.14 once 1.13 is out. > > If we stick to our cadence of cutting a release every 3 months and shipping > it 1 month later, 1.14 is due to be cut two weeks from today. However, we > haven't shipped 1.13 yet and are still struggling with some issues. > > I suggest that we postpone cutting the 1.14 release till we've actually > shipped 1.13. Once we've shipped 1.13, we should have another conversation > about timing of 1.14. I know the 1.13 release has been taxing on many > people in our community and we might want to consider giving ourselves a > little bit of a gap between releases.
Re: [Discuss] Cutting Geode 1.14
+1 to postponing 1.14. Given the limited resources we have in terms of people who shepherd the release process and ensure the quality of what we end up releasing, it would put an unsustainable amount of strain on those who have already been working extremely hard on getting 1.13 finished if we rolled right into 1.14 without time to breathe and hopefully ramp up some more people to take over parts of the release process. I'm also not in favour of abandoning 1.13 entirely, as there's been a huge effort on the part of some community members to get it into a good state to release, and dropping 1.13 now would effectively be seeing all that work go to waste. It also wouldn't address the core issue that those most heavily involved in the release process and in identifying and addressing potential release blockers are in danger of being exhausted by the non-stop process of finding and fixing bugs in the release, since 1.14 will have all of the same blockers that 1.13 currently has, plus an undetermined number of additional ones that we may not know about yet. From: Jacob Barrett Sent: Monday, July 20, 2020 9:38 AM To: dev@geode.apache.org Subject: Re: [Discuss] Cutting Geode 1.14 Alternatively, why not abandon 1.13 and try again with 1.14? > On Jul 20, 2020, at 9:21 AM, Alexander Murmann wrote: > > Hi everyone, > > TL;DR: Let's discuss 1.14 once 1.13 is out. > > If we stick to our cadence of cutting a release every 3 months and shipping > it 1 month later, 1.14 is due to be cut two weeks from today. However, we > haven't shipped 1.13 yet and are still struggling with some issues. > > I suggest that we postpone cutting the 1.14 release till we've actually > shipped 1.13. Once we've shipped 1.13, we should have another conversation > about timing of 1.14. I know the 1.13 release has been taxing on many > people in our community and we might want to consider giving ourselves a > little bit of a gap between releases.
Re: [Discuss] Cutting Geode 1.14
I think re-cutting 1.13 from current develop is interesting, but I think I agree with Donal that the amount of additional risk might not be worth it. Geode 1.13 already has some cool new features like SNI support that I believe some users have been waiting for and I'd hate to not get that out for another 2 months. It also would be nice to get something out and get a little bit of a breather, rather than running the risk of another 2 months of full-steam. On Mon, Jul 20, 2020 at 9:55 AM Donal Evans wrote: > +1 to postponing 1.14. > > Given the limited resources we have in terms of people who shepherd the > release process and ensure the quality of what we end up releasing, it > would put an unsustainable amount of strain on those who have already been > working extremely hard on getting 1.13 finished if we rolled right into > 1.14 without time to breathe and hopefully ramp up some more people to take > over parts of the release process. > > I'm also not in favour of abandoning 1.13 entirely, as there's been a huge > effort on the part of some community members to get it into a good state to > release, and dropping 1.13 now would effectively be seeing all that work go > to waste. It also wouldn't address the core issue that those most heavily > involved in the release process and in identifying and addressing potential > release blockers are in danger of being exhausted by the non-stop process > of finding and fixing bugs in the release, since 1.14 will have all of the > same blockers that 1.13 currently has, plus an undetermined number of > additional ones that we may not know about yet. > > From: Jacob Barrett > Sent: Monday, July 20, 2020 9:38 AM > To: dev@geode.apache.org > Subject: Re: [Discuss] Cutting Geode 1.14 > > Alternatively, why not abandon 1.13 and try again with 1.14? > > > On Jul 20, 2020, at 9:21 AM, Alexander Murmann > wrote: > > > > Hi everyone, > > > > TL;DR: Let's discuss 1.14 once 1.13 is out. > > > > If we stick to our cadence of cutting a release every 3 months and > shipping > > it 1 month later, 1.14 is due to be cut two weeks from today. However, we > > haven't shipped 1.13 yet and are still struggling with some issues. > > > > I suggest that we postpone cutting the 1.14 release till we've actually > > shipped 1.13. Once we've shipped 1.13, we should have another > conversation > > about timing of 1.14. I know the 1.13 release has been taxing on many > > people in our community and we might want to consider giving ourselves a > > little bit of a gap between releases. > > -- Alexander J. Murmann (650) 283-1933
Re: [Discuss] Cutting Geode 1.14
The Geode community adopted a time-based quarterly cadence two years ago in the hope it would lead to higher stability and more predictable releases. The idea was that by knowing exactly when a branch cut is upcoming, developers will hold off on high-risk changes and focus more on hardening as the cut date approaches. The flip side was that the next release cut was never more than 3 months away, making it more palatable to delay features to the next release for the greater good. I am concerned about reneging on this promise so close to a date that developers have already been planning around. Develop has seen 259 commits since support/1.13 was cut, which is a full release worth. Some feature work such as geode-redis is eagerly anticipating a prompt branch cut and swift release thereafter. Are you proposing to abandon time-based release cadence entirely? If not, can you provide more detail on the new schedule you are envisioning (e.g. still 4x/yr, but shifted out by a month? Or move to 3x/yr, starting by delaying 1.14 by a month?). I don't know if this is the forum to reflect on *why* it takes so long to stabilize from develop and get to something releasable, but if we accept that the release process routinely takes 2-3 months (not the 1 month our quarterly cadence was predicated on), then taking this opportunity to move to a 3x/year cadence might be the smart play. -Owen On 7/20/20, 9:55 AM, "Donal Evans" wrote: +1 to postponing 1.14. Given the limited resources we have in terms of people who shepherd the release process and ensure the quality of what we end up releasing, it would put an unsustainable amount of strain on those who have already been working extremely hard on getting 1.13 finished if we rolled right into 1.14 without time to breathe and hopefully ramp up some more people to take over parts of the release process. I'm also not in favour of abandoning 1.13 entirely, as there's been a huge effort on the part of some community members to get it into a good state to release, and dropping 1.13 now would effectively be seeing all that work go to waste. It also wouldn't address the core issue that those most heavily involved in the release process and in identifying and addressing potential release blockers are in danger of being exhausted by the non-stop process of finding and fixing bugs in the release, since 1.14 will have all of the same blockers that 1.13 currently has, plus an undetermined number of additional ones that we may not know about yet. From: Jacob Barrett Sent: Monday, July 20, 2020 9:38 AM To: dev@geode.apache.org Subject: Re: [Discuss] Cutting Geode 1.14 Alternatively, why not abandon 1.13 and try again with 1.14? > On Jul 20, 2020, at 9:21 AM, Alexander Murmann wrote: > > Hi everyone, > > TL;DR: Let's discuss 1.14 once 1.13 is out. > > If we stick to our cadence of cutting a release every 3 months and shipping > it 1 month later, 1.14 is due to be cut two weeks from today. However, we > haven't shipped 1.13 yet and are still struggling with some issues. > > I suggest that we postpone cutting the 1.14 release till we've actually > shipped 1.13. Once we've shipped 1.13, we should have another conversation > about timing of 1.14. I know the 1.13 release has been taxing on many > people in our community and we might want to consider giving ourselves a > little bit of a gap between releases.
Re: [Discuss] Cutting Geode 1.14
Hi Owen, I am not proposing to abandon our time-based releases. It's unprecedented for one of our releases to take this long. Even if we were to cut the release now, it would likely not receive any attention till 1.13 is out. So I don't think there is any benefit in cutting the release now. In addition there are all the downsides, I discussed above that are unique to this situation. An aside: > [..] developers will hold off on high-risk changes and focus more on > hardening as the cut date approaches. > To me that wasn't ever part of the reason for timed releases, but predictability for users and for developers to know by when features need to be done to ship. If we feel a change is risky, let's write tests till we feel it's safe. On Mon, Jul 20, 2020 at 12:19 PM Owen Nichols wrote: > The Geode community adopted a time-based quarterly cadence two years ago > in the hope it would lead to higher stability and more predictable > releases. The idea was that by knowing exactly when a branch cut is > upcoming, developers will hold off on high-risk changes and focus more on > hardening as the cut date approaches. The flip side was that the next > release cut was never more than 3 months away, making it more palatable to > delay features to the next release for the greater good. > > I am concerned about reneging on this promise so close to a date that > developers have already been planning around. Develop has seen 259 commits > since support/1.13 was cut, which is a full release worth. Some feature > work such as geode-redis is eagerly anticipating a prompt branch cut and > swift release thereafter. > > Are you proposing to abandon time-based release cadence entirely? If not, > can you provide more detail on the new schedule you are envisioning (e.g. > still 4x/yr, but shifted out by a month? Or move to 3x/yr, starting by > delaying 1.14 by a month?). > > I don't know if this is the forum to reflect on *why* it takes so long to > stabilize from develop and get to something releasable, but if we accept > that the release process routinely takes 2-3 months (not the 1 month our > quarterly cadence was predicated on), then taking this opportunity to move > to a 3x/year cadence might be the smart play. > > -Owen > > On 7/20/20, 9:55 AM, "Donal Evans" wrote: > > +1 to postponing 1.14. > > Given the limited resources we have in terms of people who shepherd > the release process and ensure the quality of what we end up releasing, it > would put an unsustainable amount of strain on those who have already been > working extremely hard on getting 1.13 finished if we rolled right into > 1.14 without time to breathe and hopefully ramp up some more people to take > over parts of the release process. > > I'm also not in favour of abandoning 1.13 entirely, as there's been a > huge effort on the part of some community members to get it into a good > state to release, and dropping 1.13 now would effectively be seeing all > that work go to waste. It also wouldn't address the core issue that those > most heavily involved in the release process and in identifying and > addressing potential release blockers are in danger of being exhausted by > the non-stop process of finding and fixing bugs in the release, since 1.14 > will have all of the same blockers that 1.13 currently has, plus an > undetermined number of additional ones that we may not know about yet. > > From: Jacob Barrett > Sent: Monday, July 20, 2020 9:38 AM > To: dev@geode.apache.org > Subject: Re: [Discuss] Cutting Geode 1.14 > > Alternatively, why not abandon 1.13 and try again with 1.14? > > > On Jul 20, 2020, at 9:21 AM, Alexander Murmann > wrote: > > > > Hi everyone, > > > > TL;DR: Let's discuss 1.14 once 1.13 is out. > > > > If we stick to our cadence of cutting a release every 3 months and > shipping > > it 1 month later, 1.14 is due to be cut two weeks from today. > However, we > > haven't shipped 1.13 yet and are still struggling with some issues. > > > > I suggest that we postpone cutting the 1.14 release till we've > actually > > shipped 1.13. Once we've shipped 1.13, we should have another > conversation > > about timing of 1.14. I know the 1.13 release has been taxing on many > > people in our community and we might want to consider giving > ourselves a > > little bit of a gap between releases. > > >
Re: [Discuss] Cutting Geode 1.14
Current schedule for cutting support branches is: Aug 3, 2020: cut support/1.14 Nov 2, 2020: cut support/1.15 Feb 1, 2021: cut support/1.16 May 3, 2021: cut support/1.17 I have a hard time understanding how anyone can trust that our schedule is "time-based" if we can change the dates at the last minute. But, I am reminded that this is only a discussion thread at this point, not a proposal yet. If it does become a proposal, I would just like to see concrete dates proposed for the next few branch cuts. Any change to the 1.14 branch cut date almost certainly must affect subsequent branch cut dates. I agree that there needs to be some downtime in between release cycles. Given that we came up with the quarterly cadence using an assumption of 1 month to get a release out, but we've found that it actually takes 2-3 months, maybe the quarterly cadence is just too aggressive? On 7/20/20, 3:12 PM, "Alexander Murmann" wrote: Hi Owen, I am not proposing to abandon our time-based releases. It's unprecedented for one of our releases to take this long. Even if we were to cut the release now, it would likely not receive any attention till 1.13 is out. So I don't think there is any benefit in cutting the release now. In addition there are all the downsides, I discussed above that are unique to this situation. An aside: > [..] developers will hold off on high-risk changes and focus more on > hardening as the cut date approaches. > To me that wasn't ever part of the reason for timed releases, but predictability for users and for developers to know by when features need to be done to ship. If we feel a change is risky, let's write tests till we feel it's safe. On Mon, Jul 20, 2020 at 12:19 PM Owen Nichols wrote: > The Geode community adopted a time-based quarterly cadence two years ago > in the hope it would lead to higher stability and more predictable > releases. The idea was that by knowing exactly when a branch cut is > upcoming, developers will hold off on high-risk changes and focus more on > hardening as the cut date approaches. The flip side was that the next > release cut was never more than 3 months away, making it more palatable to > delay features to the next release for the greater good. > > I am concerned about reneging on this promise so close to a date that > developers have already been planning around. Develop has seen 259 commits > since support/1.13 was cut, which is a full release worth. Some feature > work such as geode-redis is eagerly anticipating a prompt branch cut and > swift release thereafter. > > Are you proposing to abandon time-based release cadence entirely? If not, > can you provide more detail on the new schedule you are envisioning (e.g. > still 4x/yr, but shifted out by a month? Or move to 3x/yr, starting by > delaying 1.14 by a month?). > > I don't know if this is the forum to reflect on *why* it takes so long to > stabilize from develop and get to something releasable, but if we accept > that the release process routinely takes 2-3 months (not the 1 month our > quarterly cadence was predicated on), then taking this opportunity to move > to a 3x/year cadence might be the smart play. > > -Owen > > On 7/20/20, 9:55 AM, "Donal Evans" wrote: > > +1 to postponing 1.14. > > Given the limited resources we have in terms of people who shepherd > the release process and ensure the quality of what we end up releasing, it > would put an unsustainable amount of strain on those who have already been > working extremely hard on getting 1.13 finished if we rolled right into > 1.14 without time to breathe and hopefully ramp up some more people to take > over parts of the release process. > > I'm also not in favour of abandoning 1.13 entirely, as there's been a > huge effort on the part of some community members to get it into a good > state to release, and dropping 1.13 now would effectively be seeing all > that work go to waste. It also wouldn't address the core issue that those > most heavily involved in the release process and in identifying and > addressing potential release blockers are in danger of being exhausted by > the non-stop process of finding and fixing bugs in the release, since 1.14 > will have all of the same blockers that 1.13 currently has, plus an > undetermined number of additional ones that we may not know about yet. > > From: Jacob Barrett > Sent: Monday, July 20, 2020 9:38 AM > To: dev@geode.apache.org > Subject: Re: [Discuss] Cutting Geode 1.14 > > Alternatively, why not abandon 1.13 and try again with 1.14? > > > On Jul 20, 2020, at 9:21 AM, Alexander Murmann > wrote: > >
