You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Alexander Murmann <am...@apache.org> on 2020/07/28 23:34:25 UTC
[PROPOSAL] Postpone Geode 1.14
Hi all,
As mentioned on the previous discuss thread, I propose to hold off cutting
1.14 until we have shipped 1.13.
Once we have shipped 1.13, we should discuss when we want to cut the 1.14
release. The actual ship date for Geode 1.13 is important information for
that conversation. Thus we cannot have that conversation before then.
Re: [DISCUSS] Geode 1.14
Posted by John Hutchison <hu...@vmware.com>.
Apologies if this detracts from the conversation of folks who have much more in depth knowledge of the codebase than I do- please feel free to ignore if this seems off base.
As a non-committing contributor who works mostly on code outside of core Geode, it seems like an always shippable develop would go a long way towards keeping the overall process feeling healthy. It is, however, frustrating to think of Redis work (with relies only on minor changes to geode core, along with other core in another module) being hung up while unrelated bugs are worked on. Not to complicate the conversation (and please feel free to ignore if this has been considered and thrown out before), but I wonder if it would be feasible (or desirable ) to try get to a place where we could ship parts of the code base separately, as “plugins, ” while continuing to work on the overall health of the core application?
From: Alexander Murmann <am...@vmware.com>
Date: Monday, November 30, 2020 at 2:57 PM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [DISCUSS] Geode 1.14
Hi all,
Thanks, Owen for reminding us all of this topic!
I wonder how we feel about the state of develop right now. If we cut 1.14 right now, it will make it easier to stabilize and ship it. However, I see 21 open JIRA tickets affecting 1.14.0. It might be better to have an all-hands effort to address as much as possible on develop and then cut 1.14. If we shift all attention to 1.14, develop will likely never get better. I'd love to get closer to an always shippable develop branch. That should vastly reduce future release pain and make everyday development better as well.
Thoughts?
________________________________
From: Jens Deppe <jd...@vmware.com>
Sent: Wednesday, November 25, 2020 20:11
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [DISCUSS] Geode 1.14
Hi Owen,
Thanks for starting this conversation and especially for volunteering as Release Manager!
Since we're already a couple of quarters 'behind', in terms of releases, I'd prefer cutting the 1.14 branch ASAP. Leaving it until Feb means we'll have 9 months of changes to stabilize. How long might that take to finally get shipped? (rhetorical).
--Jens
On 11/25/20, 6:05 PM, "Owen Nichols" <on...@vmware.com> wrote:
The trigger in @Alexander’s July 28 proposal to postpone 1.14 has been met (we shipped 1.13).
It’s time to discuss when we want to cut the 1.14 branch. I will volunteer as Release Manager.
Below are all release dates since Geode adopted a time-based release cadence.
Minor releases:
1.13 branch cut May 4 2020, 1.13.0 shipped Sep 9 2020
1.12 branch cut Feb 4 2020 1.12.0 shipped Mar 31 2020
1.11 branch cut Nov 4 2019 1.11.0 shipped Dec 31 2019
1.10 branch cut Aug 2 2019 1.10.0 shipped Sep 26 2019
1.9 branch cut Feb 19 2019 1.9.0 shipped Apr 24 2019
1.8 branch cut Nov 1 2018 1.8.0 shipped Dec 12 2018
Patch releases:
1.13.1 shipped Nov 18 2020
1.9.2 shipped Nov 14 2019
1.9.1 shipped Sep 6 2019
I’ll toss out an initial suggestion: Let’s cut the support/1.14 branch on the next date in the original quarterly cadence: Feb 1 2021.
-Owen
From: Alexander Murmann <am...@apache.org>
Date: Tuesday, July 28, 2020 at 4:34 PM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: [PROPOSAL] Postpone Geode 1.14
Hi all,
As mentioned on the previous discuss thread, I propose to hold off cutting
1.14 until we have shipped 1.13.
Once we have shipped 1.13, we should discuss when we want to cut the 1.14
release. The actual ship date for Geode 1.13 is important information for
that conversation. Thus we cannot have that conversation before then.
Re: [DISCUSS] Geode 1.14
Posted by Owen Nichols <on...@vmware.com>.
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" <nn...@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 <am...@vmware.com>
Sent: Wednesday, January 6, 2021 7:39 AM
To: dev@geode.apache.org <de...@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 <am...@vmware.com>
Sent: Tuesday, January 5, 2021 08:34
To: dev@geode.apache.org <de...@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 <ja...@vmware.com>
Sent: Monday, January 4, 2021 16:40
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [DISCUSS] Geode 1.14
> On Jan 4, 2021, at 3:42 PM, Owen Nichols <on...@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
Re: [DISCUSS] Geode 1.14
Posted by Nabarun Nag <nn...@vmware.com>.
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 <am...@vmware.com>
Sent: Wednesday, January 6, 2021 7:39 AM
To: dev@geode.apache.org <de...@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 <am...@vmware.com>
Sent: Tuesday, January 5, 2021 08:34
To: dev@geode.apache.org <de...@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%7Cnnag%40vmware.com%7C2c2660c80a554ccce53508d8b259519e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637455443999560351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7YGPuXSCTmXtwtlhXeI3i2pylGFxzppRXvHMJAxxtY8%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 <ja...@vmware.com>
Sent: Monday, January 4, 2021 16:40
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [DISCUSS] Geode 1.14
> On Jan 4, 2021, at 3:42 PM, Owen Nichols <on...@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
Re: [DISCUSS] Geode 1.14
Posted by Alexander Murmann <am...@vmware.com>.
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 <am...@vmware.com>
Sent: Tuesday, January 5, 2021 08:34
To: dev@geode.apache.org <de...@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%7Camurmann%40vmware.com%7Ce3c64a22854b44232a2708d8b197bfa9%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637454612604312895%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=rAFXAsnkIWtvxPcv%2BcGnoU5m9B8aCIOLv6bn3bFmEN8%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 <ja...@vmware.com>
Sent: Monday, January 4, 2021 16:40
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [DISCUSS] Geode 1.14
> On Jan 4, 2021, at 3:42 PM, Owen Nichols <on...@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
Re: [DISCUSS] Geode 1.14
Posted by Alexander Murmann <am...@vmware.com>.
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://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12336052>. 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 <ja...@vmware.com>
Sent: Monday, January 4, 2021 16:40
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [DISCUSS] Geode 1.14
> On Jan 4, 2021, at 3:42 PM, Owen Nichols <on...@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
Re: [DISCUSS] Geode 1.14
Posted by Jacob Barrett <ja...@vmware.com>.
> On Jan 4, 2021, at 3:42 PM, Owen Nichols <on...@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
Re: [DISCUSS] Geode 1.14
Posted by Jianxia Chen <jc...@apache.org>.
A JIRA dashboard for 1.14.0 might help. Do we currently have one? I am not
sure whether there is some JIRA label introduced for the release of 1.14.0.
A quick search of open JIRA that affects 1.14.0 returns 29 tickets.
Jianxia
On Mon, Jan 4, 2021 at 3:43 PM Owen Nichols <on...@vmware.com> wrote:
> How to tell whether develop is stable?
>
> From: Jacob Barrett <ja...@vmware.com>
> Date: Monday, January 4, 2021 at 8:59 AM
> To: dev@geode.apache.org <de...@geode.apache.org>
> Subject: Re: [DISCUSS] Geode 1.14
> Keep develop stable, cut when we want to release. If develop isn’t stable
> we don’t cut until it is. There is no reason we can’t keep develop stable.
> If develop is stable then there is no reason we can’t release when we want
> to, whether that is a date or after a feature.
>
> -Jake
>
>
> > On Jan 4, 2021, at 7:22 AM, Anilkumar Gingade <ag...@vmware.com>
> wrote:
> >
> > My recommendation will be:
> > - Identify, Prioritize, Merge 1.14 related work
> > - Stabilize. Cut the branch and Stabilize again (to test any new changes
> added during first stabilize period)
> >
> > -Anil.
> >
> >
> > On 12/18/20, 2:26 PM, "Mark Hanson" <ha...@vmware.com> wrote:
> >
> > I support the cut on a predetermined date. But I will be ok with the
> Stabilize first approach, because I think that having a stable build is a
> prerequisite for any time based model. But like all things, this is a smell
> that we have to do this... The other thing is that specifying a date or a
> window of time in my opinion is crucial to ensuring freshly baked features
> are not merged until we cut the release. The window need not be very long a
> day or two as an example. With the volume of defects that we need to
> assess/fix maintaining control of develop seems important. So I would
> propose that we give notice of when we are looking to cut the branch (once
> we have made adequate determinations for the defects).
> >
> > Thanks,
> > Mark
> >
> > On 12/18/20, 12:09 PM, "Owen Nichols" <on...@vmware.com> wrote:
> >
> > To summarize this thread so far:
> > @Robert and @Jens seem to favor “cut then stabilize”
> > @Alexander and @John seem to favor “stabilize then cut”
> > No one seems to favor “cut on a predetermined date” (at least for
> 1.14)
> >
> > @John also made a creative suggestion that maybe 1.14 doesn’t
> have to be cut from latest develop…what if we cut it from support/1.13 and
> then backport just the redis changes (in parallel with continuing to
> stabilize what’s currently on develop into a 1.15 release).
> >
> > For now let’s try to proceed on the “stabilize then cut” plan.
> All committers, please hold off on merging big refactorings or other
> high-risk changes to develop until after the branch is cut. Let’s regroup
> next month and try to clarify exactly which GEODE Jira tickets we need to
> focus on to make sure 1.14 is our best release.
> >
> > From: Owen Nichols <on...@vmware.com>
> > Date: Tuesday, December 1, 2020 at 12:26 PM
> > To: dev@geode.apache.org <de...@geode.apache.org>
> > Subject: Re: [DISCUSS] Geode 1.14
> > If someone wants to propose a list of must-fix Jira tickets
> before we can cut the branch, I see that as a shift from a time-based to
> feature-based branch-cut strategy. Might be fun to try?
> >
> > Given the distributed nature of the Geode community, picking a
> date and sticking to it allows decentralized decision-making (each
> contributor can plan on their own what they can finish and/or how they can
> help get develop as stable as possible by that date).
> >
> > To answer your question: the current state of develop feels
> “pretty good” to me. Knowing that only critical fixes will be allowed onto
> the branch once cut, the question is really about features. It sounds like
> there is redis work we’d like to ship. Anything else nearly-done we should
> considering waiting on?
> >
> > From: Alexander Murmann <am...@vmware.com>
> > Date: Monday, November 30, 2020 at 11:57 AM
> > To: dev@geode.apache.org <de...@geode.apache.org>
> > Subject: Re: [DISCUSS] Geode 1.14
> > Hi all,
> >
> > Thanks, Owen for reminding us all of this topic!
> >
> > I wonder how we feel about the state of develop right now. If we
> cut 1.14 right now, it will make it easier to stabilize and ship it.
> However, I see 21 open JIRA tickets affecting 1.14.0. It might be better to
> have an all-hands effort to address as much as possible on develop and then
> cut 1.14. If we shift all attention to 1.14, develop will likely never get
> better. I'd love to get closer to an always shippable develop branch. That
> should vastly reduce future release pain and make everyday development
> better as well.
> >
> > Thoughts?
> > ________________________________
> > From: Jens Deppe <jd...@vmware.com>
> > Sent: Wednesday, November 25, 2020 20:11
> > To: dev@geode.apache.org <de...@geode.apache.org>
> > Subject: Re: [DISCUSS] Geode 1.14
> >
> > Hi Owen,
> >
> > Thanks for starting this conversation and especially for
> volunteering as Release Manager!
> >
> > Since we're already a couple of quarters 'behind', in terms of
> releases, I'd prefer cutting the 1.14 branch ASAP. Leaving it until Feb
> means we'll have 9 months of changes to stabilize. How long might that take
> to finally get shipped? (rhetorical).
> >
> > --Jens
> >
> > On 11/25/20, 6:05 PM, "Owen Nichols" <on...@vmware.com> wrote:
> >
> > The trigger in @Alexander’s July 28 proposal to postpone 1.14
> has been met (we shipped 1.13).
> > It’s time to discuss when we want to cut the 1.14 branch. I
> will volunteer as Release Manager.
> >
> > Below are all release dates since Geode adopted a time-based
> release cadence.
> >
> > Minor releases:
> > 1.13 branch cut May 4 2020, 1.13.0 shipped Sep 9 2020
> > 1.12 branch cut Feb 4 2020 1.12.0 shipped Mar 31 2020
> > 1.11 branch cut Nov 4 2019 1.11.0 shipped Dec 31 2019
> > 1.10 branch cut Aug 2 2019 1.10.0 shipped Sep 26 2019
> > 1.9 branch cut Feb 19 2019 1.9.0 shipped Apr 24 2019
> > 1.8 branch cut Nov 1 2018 1.8.0 shipped Dec 12 2018
> >
> > Patch releases:
> > 1.13.1 shipped Nov 18 2020
> > 1.9.2 shipped Nov 14 2019
> > 1.9.1 shipped Sep 6 2019
> >
> > I’ll toss out an initial suggestion: Let’s cut the
> support/1.14 branch on the next date in the original quarterly cadence: Feb
> 1 2021.
> >
> > -Owen
> >
> > From: Alexander Murmann <am...@apache.org>
> > Date: Tuesday, July 28, 2020 at 4:34 PM
> > To: dev@geode.apache.org <de...@geode.apache.org>
> > Subject: [PROPOSAL] Postpone Geode 1.14
> > Hi all,
> >
> > As mentioned on the previous discuss thread, I propose to
> hold off cutting
> > 1.14 until we have shipped 1.13.
> >
> > Once we have shipped 1.13, we should discuss when we want to
> cut the 1.14
> > release. The actual ship date for Geode 1.13 is important
> information for
> > that conversation. Thus we cannot have that conversation
> before then.
> >
> >
>
Re: [DISCUSS] Geode 1.14
Posted by Owen Nichols <on...@vmware.com>.
How to tell whether develop is stable?
From: Jacob Barrett <ja...@vmware.com>
Date: Monday, January 4, 2021 at 8:59 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [DISCUSS] Geode 1.14
Keep develop stable, cut when we want to release. If develop isn’t stable we don’t cut until it is. There is no reason we can’t keep develop stable. If develop is stable then there is no reason we can’t release when we want to, whether that is a date or after a feature.
-Jake
> On Jan 4, 2021, at 7:22 AM, Anilkumar Gingade <ag...@vmware.com> wrote:
>
> My recommendation will be:
> - Identify, Prioritize, Merge 1.14 related work
> - Stabilize. Cut the branch and Stabilize again (to test any new changes added during first stabilize period)
>
> -Anil.
>
>
> On 12/18/20, 2:26 PM, "Mark Hanson" <ha...@vmware.com> wrote:
>
> I support the cut on a predetermined date. But I will be ok with the Stabilize first approach, because I think that having a stable build is a prerequisite for any time based model. But like all things, this is a smell that we have to do this... The other thing is that specifying a date or a window of time in my opinion is crucial to ensuring freshly baked features are not merged until we cut the release. The window need not be very long a day or two as an example. With the volume of defects that we need to assess/fix maintaining control of develop seems important. So I would propose that we give notice of when we are looking to cut the branch (once we have made adequate determinations for the defects).
>
> Thanks,
> Mark
>
> On 12/18/20, 12:09 PM, "Owen Nichols" <on...@vmware.com> wrote:
>
> To summarize this thread so far:
> @Robert and @Jens seem to favor “cut then stabilize”
> @Alexander and @John seem to favor “stabilize then cut”
> No one seems to favor “cut on a predetermined date” (at least for 1.14)
>
> @John also made a creative suggestion that maybe 1.14 doesn’t have to be cut from latest develop…what if we cut it from support/1.13 and then backport just the redis changes (in parallel with continuing to stabilize what’s currently on develop into a 1.15 release).
>
> For now let’s try to proceed on the “stabilize then cut” plan. All committers, please hold off on merging big refactorings or other high-risk changes to develop until after the branch is cut. Let’s regroup next month and try to clarify exactly which GEODE Jira tickets we need to focus on to make sure 1.14 is our best release.
>
> From: Owen Nichols <on...@vmware.com>
> Date: Tuesday, December 1, 2020 at 12:26 PM
> To: dev@geode.apache.org <de...@geode.apache.org>
> Subject: Re: [DISCUSS] Geode 1.14
> If someone wants to propose a list of must-fix Jira tickets before we can cut the branch, I see that as a shift from a time-based to feature-based branch-cut strategy. Might be fun to try?
>
> Given the distributed nature of the Geode community, picking a date and sticking to it allows decentralized decision-making (each contributor can plan on their own what they can finish and/or how they can help get develop as stable as possible by that date).
>
> To answer your question: the current state of develop feels “pretty good” to me. Knowing that only critical fixes will be allowed onto the branch once cut, the question is really about features. It sounds like there is redis work we’d like to ship. Anything else nearly-done we should considering waiting on?
>
> From: Alexander Murmann <am...@vmware.com>
> Date: Monday, November 30, 2020 at 11:57 AM
> To: dev@geode.apache.org <de...@geode.apache.org>
> Subject: Re: [DISCUSS] Geode 1.14
> Hi all,
>
> Thanks, Owen for reminding us all of this topic!
>
> I wonder how we feel about the state of develop right now. If we cut 1.14 right now, it will make it easier to stabilize and ship it. However, I see 21 open JIRA tickets affecting 1.14.0. It might be better to have an all-hands effort to address as much as possible on develop and then cut 1.14. If we shift all attention to 1.14, develop will likely never get better. I'd love to get closer to an always shippable develop branch. That should vastly reduce future release pain and make everyday development better as well.
>
> Thoughts?
> ________________________________
> From: Jens Deppe <jd...@vmware.com>
> Sent: Wednesday, November 25, 2020 20:11
> To: dev@geode.apache.org <de...@geode.apache.org>
> Subject: Re: [DISCUSS] Geode 1.14
>
> Hi Owen,
>
> Thanks for starting this conversation and especially for volunteering as Release Manager!
>
> Since we're already a couple of quarters 'behind', in terms of releases, I'd prefer cutting the 1.14 branch ASAP. Leaving it until Feb means we'll have 9 months of changes to stabilize. How long might that take to finally get shipped? (rhetorical).
>
> --Jens
>
> On 11/25/20, 6:05 PM, "Owen Nichols" <on...@vmware.com> wrote:
>
> The trigger in @Alexander’s July 28 proposal to postpone 1.14 has been met (we shipped 1.13).
> It’s time to discuss when we want to cut the 1.14 branch. I will volunteer as Release Manager.
>
> Below are all release dates since Geode adopted a time-based release cadence.
>
> Minor releases:
> 1.13 branch cut May 4 2020, 1.13.0 shipped Sep 9 2020
> 1.12 branch cut Feb 4 2020 1.12.0 shipped Mar 31 2020
> 1.11 branch cut Nov 4 2019 1.11.0 shipped Dec 31 2019
> 1.10 branch cut Aug 2 2019 1.10.0 shipped Sep 26 2019
> 1.9 branch cut Feb 19 2019 1.9.0 shipped Apr 24 2019
> 1.8 branch cut Nov 1 2018 1.8.0 shipped Dec 12 2018
>
> Patch releases:
> 1.13.1 shipped Nov 18 2020
> 1.9.2 shipped Nov 14 2019
> 1.9.1 shipped Sep 6 2019
>
> I’ll toss out an initial suggestion: Let’s cut the support/1.14 branch on the next date in the original quarterly cadence: Feb 1 2021.
>
> -Owen
>
> From: Alexander Murmann <am...@apache.org>
> Date: Tuesday, July 28, 2020 at 4:34 PM
> To: dev@geode.apache.org <de...@geode.apache.org>
> Subject: [PROPOSAL] Postpone Geode 1.14
> Hi all,
>
> As mentioned on the previous discuss thread, I propose to hold off cutting
> 1.14 until we have shipped 1.13.
>
> Once we have shipped 1.13, we should discuss when we want to cut the 1.14
> release. The actual ship date for Geode 1.13 is important information for
> that conversation. Thus we cannot have that conversation before then.
>
>
Re: [DISCUSS] Geode 1.14
Posted by Jacob Barrett <ja...@vmware.com>.
Keep develop stable, cut when we want to release. If develop isn’t stable we don’t cut until it is. There is no reason we can’t keep develop stable. If develop is stable then there is no reason we can’t release when we want to, whether that is a date or after a feature.
-Jake
> On Jan 4, 2021, at 7:22 AM, Anilkumar Gingade <ag...@vmware.com> wrote:
>
> My recommendation will be:
> - Identify, Prioritize, Merge 1.14 related work
> - Stabilize. Cut the branch and Stabilize again (to test any new changes added during first stabilize period)
>
> -Anil.
>
>
> On 12/18/20, 2:26 PM, "Mark Hanson" <ha...@vmware.com> wrote:
>
> I support the cut on a predetermined date. But I will be ok with the Stabilize first approach, because I think that having a stable build is a prerequisite for any time based model. But like all things, this is a smell that we have to do this... The other thing is that specifying a date or a window of time in my opinion is crucial to ensuring freshly baked features are not merged until we cut the release. The window need not be very long a day or two as an example. With the volume of defects that we need to assess/fix maintaining control of develop seems important. So I would propose that we give notice of when we are looking to cut the branch (once we have made adequate determinations for the defects).
>
> Thanks,
> Mark
>
> On 12/18/20, 12:09 PM, "Owen Nichols" <on...@vmware.com> wrote:
>
> To summarize this thread so far:
> @Robert and @Jens seem to favor “cut then stabilize”
> @Alexander and @John seem to favor “stabilize then cut”
> No one seems to favor “cut on a predetermined date” (at least for 1.14)
>
> @John also made a creative suggestion that maybe 1.14 doesn’t have to be cut from latest develop…what if we cut it from support/1.13 and then backport just the redis changes (in parallel with continuing to stabilize what’s currently on develop into a 1.15 release).
>
> For now let’s try to proceed on the “stabilize then cut” plan. All committers, please hold off on merging big refactorings or other high-risk changes to develop until after the branch is cut. Let’s regroup next month and try to clarify exactly which GEODE Jira tickets we need to focus on to make sure 1.14 is our best release.
>
> From: Owen Nichols <on...@vmware.com>
> Date: Tuesday, December 1, 2020 at 12:26 PM
> To: dev@geode.apache.org <de...@geode.apache.org>
> Subject: Re: [DISCUSS] Geode 1.14
> If someone wants to propose a list of must-fix Jira tickets before we can cut the branch, I see that as a shift from a time-based to feature-based branch-cut strategy. Might be fun to try?
>
> Given the distributed nature of the Geode community, picking a date and sticking to it allows decentralized decision-making (each contributor can plan on their own what they can finish and/or how they can help get develop as stable as possible by that date).
>
> To answer your question: the current state of develop feels “pretty good” to me. Knowing that only critical fixes will be allowed onto the branch once cut, the question is really about features. It sounds like there is redis work we’d like to ship. Anything else nearly-done we should considering waiting on?
>
> From: Alexander Murmann <am...@vmware.com>
> Date: Monday, November 30, 2020 at 11:57 AM
> To: dev@geode.apache.org <de...@geode.apache.org>
> Subject: Re: [DISCUSS] Geode 1.14
> Hi all,
>
> Thanks, Owen for reminding us all of this topic!
>
> I wonder how we feel about the state of develop right now. If we cut 1.14 right now, it will make it easier to stabilize and ship it. However, I see 21 open JIRA tickets affecting 1.14.0. It might be better to have an all-hands effort to address as much as possible on develop and then cut 1.14. If we shift all attention to 1.14, develop will likely never get better. I'd love to get closer to an always shippable develop branch. That should vastly reduce future release pain and make everyday development better as well.
>
> Thoughts?
> ________________________________
> From: Jens Deppe <jd...@vmware.com>
> Sent: Wednesday, November 25, 2020 20:11
> To: dev@geode.apache.org <de...@geode.apache.org>
> Subject: Re: [DISCUSS] Geode 1.14
>
> Hi Owen,
>
> Thanks for starting this conversation and especially for volunteering as Release Manager!
>
> Since we're already a couple of quarters 'behind', in terms of releases, I'd prefer cutting the 1.14 branch ASAP. Leaving it until Feb means we'll have 9 months of changes to stabilize. How long might that take to finally get shipped? (rhetorical).
>
> --Jens
>
> On 11/25/20, 6:05 PM, "Owen Nichols" <on...@vmware.com> wrote:
>
> The trigger in @Alexander’s July 28 proposal to postpone 1.14 has been met (we shipped 1.13).
> It’s time to discuss when we want to cut the 1.14 branch. I will volunteer as Release Manager.
>
> Below are all release dates since Geode adopted a time-based release cadence.
>
> Minor releases:
> 1.13 branch cut May 4 2020, 1.13.0 shipped Sep 9 2020
> 1.12 branch cut Feb 4 2020 1.12.0 shipped Mar 31 2020
> 1.11 branch cut Nov 4 2019 1.11.0 shipped Dec 31 2019
> 1.10 branch cut Aug 2 2019 1.10.0 shipped Sep 26 2019
> 1.9 branch cut Feb 19 2019 1.9.0 shipped Apr 24 2019
> 1.8 branch cut Nov 1 2018 1.8.0 shipped Dec 12 2018
>
> Patch releases:
> 1.13.1 shipped Nov 18 2020
> 1.9.2 shipped Nov 14 2019
> 1.9.1 shipped Sep 6 2019
>
> I’ll toss out an initial suggestion: Let’s cut the support/1.14 branch on the next date in the original quarterly cadence: Feb 1 2021.
>
> -Owen
>
> From: Alexander Murmann <am...@apache.org>
> Date: Tuesday, July 28, 2020 at 4:34 PM
> To: dev@geode.apache.org <de...@geode.apache.org>
> Subject: [PROPOSAL] Postpone Geode 1.14
> Hi all,
>
> As mentioned on the previous discuss thread, I propose to hold off cutting
> 1.14 until we have shipped 1.13.
>
> Once we have shipped 1.13, we should discuss when we want to cut the 1.14
> release. The actual ship date for Geode 1.13 is important information for
> that conversation. Thus we cannot have that conversation before then.
>
>
Re: [DISCUSS] Geode 1.14
Posted by Xiaojian Zhou <zh...@vmware.com>.
My opinion:
(1) List out must fix bugs for 1.4 (I don’t think there’s any, but it’s good to review)
(2) cut the 1.4 release branch and start the stabilization period asap.
Gester
From: Anilkumar Gingade <ag...@vmware.com>
Date: Monday, January 4, 2021 at 7:23 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [DISCUSS] Geode 1.14
My recommendation will be:
- Identify, Prioritize, Merge 1.14 related work
- Stabilize. Cut the branch and Stabilize again (to test any new changes added during first stabilize period)
-Anil.
On 12/18/20, 2:26 PM, "Mark Hanson" <ha...@vmware.com> wrote:
I support the cut on a predetermined date. But I will be ok with the Stabilize first approach, because I think that having a stable build is a prerequisite for any time based model. But like all things, this is a smell that we have to do this... The other thing is that specifying a date or a window of time in my opinion is crucial to ensuring freshly baked features are not merged until we cut the release. The window need not be very long a day or two as an example. With the volume of defects that we need to assess/fix maintaining control of develop seems important. So I would propose that we give notice of when we are looking to cut the branch (once we have made adequate determinations for the defects).
Thanks,
Mark
On 12/18/20, 12:09 PM, "Owen Nichols" <on...@vmware.com> wrote:
To summarize this thread so far:
@Robert and @Jens seem to favor “cut then stabilize”
@Alexander and @John seem to favor “stabilize then cut”
No one seems to favor “cut on a predetermined date” (at least for 1.14)
@John also made a creative suggestion that maybe 1.14 doesn’t have to be cut from latest develop…what if we cut it from support/1.13 and then backport just the redis changes (in parallel with continuing to stabilize what’s currently on develop into a 1.15 release).
For now let’s try to proceed on the “stabilize then cut” plan. All committers, please hold off on merging big refactorings or other high-risk changes to develop until after the branch is cut. Let’s regroup next month and try to clarify exactly which GEODE Jira tickets we need to focus on to make sure 1.14 is our best release.
From: Owen Nichols <on...@vmware.com>
Date: Tuesday, December 1, 2020 at 12:26 PM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [DISCUSS] Geode 1.14
If someone wants to propose a list of must-fix Jira tickets before we can cut the branch, I see that as a shift from a time-based to feature-based branch-cut strategy. Might be fun to try?
Given the distributed nature of the Geode community, picking a date and sticking to it allows decentralized decision-making (each contributor can plan on their own what they can finish and/or how they can help get develop as stable as possible by that date).
To answer your question: the current state of develop feels “pretty good” to me. Knowing that only critical fixes will be allowed onto the branch once cut, the question is really about features. It sounds like there is redis work we’d like to ship. Anything else nearly-done we should considering waiting on?
From: Alexander Murmann <am...@vmware.com>
Date: Monday, November 30, 2020 at 11:57 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [DISCUSS] Geode 1.14
Hi all,
Thanks, Owen for reminding us all of this topic!
I wonder how we feel about the state of develop right now. If we cut 1.14 right now, it will make it easier to stabilize and ship it. However, I see 21 open JIRA tickets affecting 1.14.0. It might be better to have an all-hands effort to address as much as possible on develop and then cut 1.14. If we shift all attention to 1.14, develop will likely never get better. I'd love to get closer to an always shippable develop branch. That should vastly reduce future release pain and make everyday development better as well.
Thoughts?
________________________________
From: Jens Deppe <jd...@vmware.com>
Sent: Wednesday, November 25, 2020 20:11
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [DISCUSS] Geode 1.14
Hi Owen,
Thanks for starting this conversation and especially for volunteering as Release Manager!
Since we're already a couple of quarters 'behind', in terms of releases, I'd prefer cutting the 1.14 branch ASAP. Leaving it until Feb means we'll have 9 months of changes to stabilize. How long might that take to finally get shipped? (rhetorical).
--Jens
On 11/25/20, 6:05 PM, "Owen Nichols" <on...@vmware.com> wrote:
The trigger in @Alexander’s July 28 proposal to postpone 1.14 has been met (we shipped 1.13).
It’s time to discuss when we want to cut the 1.14 branch. I will volunteer as Release Manager.
Below are all release dates since Geode adopted a time-based release cadence.
Minor releases:
1.13 branch cut May 4 2020, 1.13.0 shipped Sep 9 2020
1.12 branch cut Feb 4 2020 1.12.0 shipped Mar 31 2020
1.11 branch cut Nov 4 2019 1.11.0 shipped Dec 31 2019
1.10 branch cut Aug 2 2019 1.10.0 shipped Sep 26 2019
1.9 branch cut Feb 19 2019 1.9.0 shipped Apr 24 2019
1.8 branch cut Nov 1 2018 1.8.0 shipped Dec 12 2018
Patch releases:
1.13.1 shipped Nov 18 2020
1.9.2 shipped Nov 14 2019
1.9.1 shipped Sep 6 2019
I’ll toss out an initial suggestion: Let’s cut the support/1.14 branch on the next date in the original quarterly cadence: Feb 1 2021.
-Owen
From: Alexander Murmann <am...@apache.org>
Date: Tuesday, July 28, 2020 at 4:34 PM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: [PROPOSAL] Postpone Geode 1.14
Hi all,
As mentioned on the previous discuss thread, I propose to hold off cutting
1.14 until we have shipped 1.13.
Once we have shipped 1.13, we should discuss when we want to cut the 1.14
release. The actual ship date for Geode 1.13 is important information for
that conversation. Thus we cannot have that conversation before then.
Re: [DISCUSS] Geode 1.14
Posted by Anilkumar Gingade <ag...@vmware.com>.
My recommendation will be:
- Identify, Prioritize, Merge 1.14 related work
- Stabilize. Cut the branch and Stabilize again (to test any new changes added during first stabilize period)
-Anil.
On 12/18/20, 2:26 PM, "Mark Hanson" <ha...@vmware.com> wrote:
I support the cut on a predetermined date. But I will be ok with the Stabilize first approach, because I think that having a stable build is a prerequisite for any time based model. But like all things, this is a smell that we have to do this... The other thing is that specifying a date or a window of time in my opinion is crucial to ensuring freshly baked features are not merged until we cut the release. The window need not be very long a day or two as an example. With the volume of defects that we need to assess/fix maintaining control of develop seems important. So I would propose that we give notice of when we are looking to cut the branch (once we have made adequate determinations for the defects).
Thanks,
Mark
On 12/18/20, 12:09 PM, "Owen Nichols" <on...@vmware.com> wrote:
To summarize this thread so far:
@Robert and @Jens seem to favor “cut then stabilize”
@Alexander and @John seem to favor “stabilize then cut”
No one seems to favor “cut on a predetermined date” (at least for 1.14)
@John also made a creative suggestion that maybe 1.14 doesn’t have to be cut from latest develop…what if we cut it from support/1.13 and then backport just the redis changes (in parallel with continuing to stabilize what’s currently on develop into a 1.15 release).
For now let’s try to proceed on the “stabilize then cut” plan. All committers, please hold off on merging big refactorings or other high-risk changes to develop until after the branch is cut. Let’s regroup next month and try to clarify exactly which GEODE Jira tickets we need to focus on to make sure 1.14 is our best release.
From: Owen Nichols <on...@vmware.com>
Date: Tuesday, December 1, 2020 at 12:26 PM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [DISCUSS] Geode 1.14
If someone wants to propose a list of must-fix Jira tickets before we can cut the branch, I see that as a shift from a time-based to feature-based branch-cut strategy. Might be fun to try?
Given the distributed nature of the Geode community, picking a date and sticking to it allows decentralized decision-making (each contributor can plan on their own what they can finish and/or how they can help get develop as stable as possible by that date).
To answer your question: the current state of develop feels “pretty good” to me. Knowing that only critical fixes will be allowed onto the branch once cut, the question is really about features. It sounds like there is redis work we’d like to ship. Anything else nearly-done we should considering waiting on?
From: Alexander Murmann <am...@vmware.com>
Date: Monday, November 30, 2020 at 11:57 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [DISCUSS] Geode 1.14
Hi all,
Thanks, Owen for reminding us all of this topic!
I wonder how we feel about the state of develop right now. If we cut 1.14 right now, it will make it easier to stabilize and ship it. However, I see 21 open JIRA tickets affecting 1.14.0. It might be better to have an all-hands effort to address as much as possible on develop and then cut 1.14. If we shift all attention to 1.14, develop will likely never get better. I'd love to get closer to an always shippable develop branch. That should vastly reduce future release pain and make everyday development better as well.
Thoughts?
________________________________
From: Jens Deppe <jd...@vmware.com>
Sent: Wednesday, November 25, 2020 20:11
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [DISCUSS] Geode 1.14
Hi Owen,
Thanks for starting this conversation and especially for volunteering as Release Manager!
Since we're already a couple of quarters 'behind', in terms of releases, I'd prefer cutting the 1.14 branch ASAP. Leaving it until Feb means we'll have 9 months of changes to stabilize. How long might that take to finally get shipped? (rhetorical).
--Jens
On 11/25/20, 6:05 PM, "Owen Nichols" <on...@vmware.com> wrote:
The trigger in @Alexander’s July 28 proposal to postpone 1.14 has been met (we shipped 1.13).
It’s time to discuss when we want to cut the 1.14 branch. I will volunteer as Release Manager.
Below are all release dates since Geode adopted a time-based release cadence.
Minor releases:
1.13 branch cut May 4 2020, 1.13.0 shipped Sep 9 2020
1.12 branch cut Feb 4 2020 1.12.0 shipped Mar 31 2020
1.11 branch cut Nov 4 2019 1.11.0 shipped Dec 31 2019
1.10 branch cut Aug 2 2019 1.10.0 shipped Sep 26 2019
1.9 branch cut Feb 19 2019 1.9.0 shipped Apr 24 2019
1.8 branch cut Nov 1 2018 1.8.0 shipped Dec 12 2018
Patch releases:
1.13.1 shipped Nov 18 2020
1.9.2 shipped Nov 14 2019
1.9.1 shipped Sep 6 2019
I’ll toss out an initial suggestion: Let’s cut the support/1.14 branch on the next date in the original quarterly cadence: Feb 1 2021.
-Owen
From: Alexander Murmann <am...@apache.org>
Date: Tuesday, July 28, 2020 at 4:34 PM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: [PROPOSAL] Postpone Geode 1.14
Hi all,
As mentioned on the previous discuss thread, I propose to hold off cutting
1.14 until we have shipped 1.13.
Once we have shipped 1.13, we should discuss when we want to cut the 1.14
release. The actual ship date for Geode 1.13 is important information for
that conversation. Thus we cannot have that conversation before then.
Re: [DISCUSS] Geode 1.14
Posted by Mark Hanson <ha...@vmware.com>.
I support the cut on a predetermined date. But I will be ok with the Stabilize first approach, because I think that having a stable build is a prerequisite for any time based model. But like all things, this is a smell that we have to do this... The other thing is that specifying a date or a window of time in my opinion is crucial to ensuring freshly baked features are not merged until we cut the release. The window need not be very long a day or two as an example. With the volume of defects that we need to assess/fix maintaining control of develop seems important. So I would propose that we give notice of when we are looking to cut the branch (once we have made adequate determinations for the defects).
Thanks,
Mark
On 12/18/20, 12:09 PM, "Owen Nichols" <on...@vmware.com> wrote:
To summarize this thread so far:
@Robert and @Jens seem to favor “cut then stabilize”
@Alexander and @John seem to favor “stabilize then cut”
No one seems to favor “cut on a predetermined date” (at least for 1.14)
@John also made a creative suggestion that maybe 1.14 doesn’t have to be cut from latest develop…what if we cut it from support/1.13 and then backport just the redis changes (in parallel with continuing to stabilize what’s currently on develop into a 1.15 release).
For now let’s try to proceed on the “stabilize then cut” plan. All committers, please hold off on merging big refactorings or other high-risk changes to develop until after the branch is cut. Let’s regroup next month and try to clarify exactly which GEODE Jira tickets we need to focus on to make sure 1.14 is our best release.
From: Owen Nichols <on...@vmware.com>
Date: Tuesday, December 1, 2020 at 12:26 PM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [DISCUSS] Geode 1.14
If someone wants to propose a list of must-fix Jira tickets before we can cut the branch, I see that as a shift from a time-based to feature-based branch-cut strategy. Might be fun to try?
Given the distributed nature of the Geode community, picking a date and sticking to it allows decentralized decision-making (each contributor can plan on their own what they can finish and/or how they can help get develop as stable as possible by that date).
To answer your question: the current state of develop feels “pretty good” to me. Knowing that only critical fixes will be allowed onto the branch once cut, the question is really about features. It sounds like there is redis work we’d like to ship. Anything else nearly-done we should considering waiting on?
From: Alexander Murmann <am...@vmware.com>
Date: Monday, November 30, 2020 at 11:57 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [DISCUSS] Geode 1.14
Hi all,
Thanks, Owen for reminding us all of this topic!
I wonder how we feel about the state of develop right now. If we cut 1.14 right now, it will make it easier to stabilize and ship it. However, I see 21 open JIRA tickets affecting 1.14.0. It might be better to have an all-hands effort to address as much as possible on develop and then cut 1.14. If we shift all attention to 1.14, develop will likely never get better. I'd love to get closer to an always shippable develop branch. That should vastly reduce future release pain and make everyday development better as well.
Thoughts?
________________________________
From: Jens Deppe <jd...@vmware.com>
Sent: Wednesday, November 25, 2020 20:11
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [DISCUSS] Geode 1.14
Hi Owen,
Thanks for starting this conversation and especially for volunteering as Release Manager!
Since we're already a couple of quarters 'behind', in terms of releases, I'd prefer cutting the 1.14 branch ASAP. Leaving it until Feb means we'll have 9 months of changes to stabilize. How long might that take to finally get shipped? (rhetorical).
--Jens
On 11/25/20, 6:05 PM, "Owen Nichols" <on...@vmware.com> wrote:
The trigger in @Alexander’s July 28 proposal to postpone 1.14 has been met (we shipped 1.13).
It’s time to discuss when we want to cut the 1.14 branch. I will volunteer as Release Manager.
Below are all release dates since Geode adopted a time-based release cadence.
Minor releases:
1.13 branch cut May 4 2020, 1.13.0 shipped Sep 9 2020
1.12 branch cut Feb 4 2020 1.12.0 shipped Mar 31 2020
1.11 branch cut Nov 4 2019 1.11.0 shipped Dec 31 2019
1.10 branch cut Aug 2 2019 1.10.0 shipped Sep 26 2019
1.9 branch cut Feb 19 2019 1.9.0 shipped Apr 24 2019
1.8 branch cut Nov 1 2018 1.8.0 shipped Dec 12 2018
Patch releases:
1.13.1 shipped Nov 18 2020
1.9.2 shipped Nov 14 2019
1.9.1 shipped Sep 6 2019
I’ll toss out an initial suggestion: Let’s cut the support/1.14 branch on the next date in the original quarterly cadence: Feb 1 2021.
-Owen
From: Alexander Murmann <am...@apache.org>
Date: Tuesday, July 28, 2020 at 4:34 PM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: [PROPOSAL] Postpone Geode 1.14
Hi all,
As mentioned on the previous discuss thread, I propose to hold off cutting
1.14 until we have shipped 1.13.
Once we have shipped 1.13, we should discuss when we want to cut the 1.14
release. The actual ship date for Geode 1.13 is important information for
that conversation. Thus we cannot have that conversation before then.
Re: [DISCUSS] Geode 1.14
Posted by Owen Nichols <on...@vmware.com>.
To summarize this thread so far:
@Robert and @Jens seem to favor “cut then stabilize”
@Alexander and @John seem to favor “stabilize then cut”
No one seems to favor “cut on a predetermined date” (at least for 1.14)
@John also made a creative suggestion that maybe 1.14 doesn’t have to be cut from latest develop…what if we cut it from support/1.13 and then backport just the redis changes (in parallel with continuing to stabilize what’s currently on develop into a 1.15 release).
For now let’s try to proceed on the “stabilize then cut” plan. All committers, please hold off on merging big refactorings or other high-risk changes to develop until after the branch is cut. Let’s regroup next month and try to clarify exactly which GEODE Jira tickets we need to focus on to make sure 1.14 is our best release.
From: Owen Nichols <on...@vmware.com>
Date: Tuesday, December 1, 2020 at 12:26 PM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [DISCUSS] Geode 1.14
If someone wants to propose a list of must-fix Jira tickets before we can cut the branch, I see that as a shift from a time-based to feature-based branch-cut strategy. Might be fun to try?
Given the distributed nature of the Geode community, picking a date and sticking to it allows decentralized decision-making (each contributor can plan on their own what they can finish and/or how they can help get develop as stable as possible by that date).
To answer your question: the current state of develop feels “pretty good” to me. Knowing that only critical fixes will be allowed onto the branch once cut, the question is really about features. It sounds like there is redis work we’d like to ship. Anything else nearly-done we should considering waiting on?
From: Alexander Murmann <am...@vmware.com>
Date: Monday, November 30, 2020 at 11:57 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [DISCUSS] Geode 1.14
Hi all,
Thanks, Owen for reminding us all of this topic!
I wonder how we feel about the state of develop right now. If we cut 1.14 right now, it will make it easier to stabilize and ship it. However, I see 21 open JIRA tickets affecting 1.14.0. It might be better to have an all-hands effort to address as much as possible on develop and then cut 1.14. If we shift all attention to 1.14, develop will likely never get better. I'd love to get closer to an always shippable develop branch. That should vastly reduce future release pain and make everyday development better as well.
Thoughts?
________________________________
From: Jens Deppe <jd...@vmware.com>
Sent: Wednesday, November 25, 2020 20:11
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [DISCUSS] Geode 1.14
Hi Owen,
Thanks for starting this conversation and especially for volunteering as Release Manager!
Since we're already a couple of quarters 'behind', in terms of releases, I'd prefer cutting the 1.14 branch ASAP. Leaving it until Feb means we'll have 9 months of changes to stabilize. How long might that take to finally get shipped? (rhetorical).
--Jens
On 11/25/20, 6:05 PM, "Owen Nichols" <on...@vmware.com> wrote:
The trigger in @Alexander’s July 28 proposal to postpone 1.14 has been met (we shipped 1.13).
It’s time to discuss when we want to cut the 1.14 branch. I will volunteer as Release Manager.
Below are all release dates since Geode adopted a time-based release cadence.
Minor releases:
1.13 branch cut May 4 2020, 1.13.0 shipped Sep 9 2020
1.12 branch cut Feb 4 2020 1.12.0 shipped Mar 31 2020
1.11 branch cut Nov 4 2019 1.11.0 shipped Dec 31 2019
1.10 branch cut Aug 2 2019 1.10.0 shipped Sep 26 2019
1.9 branch cut Feb 19 2019 1.9.0 shipped Apr 24 2019
1.8 branch cut Nov 1 2018 1.8.0 shipped Dec 12 2018
Patch releases:
1.13.1 shipped Nov 18 2020
1.9.2 shipped Nov 14 2019
1.9.1 shipped Sep 6 2019
I’ll toss out an initial suggestion: Let’s cut the support/1.14 branch on the next date in the original quarterly cadence: Feb 1 2021.
-Owen
From: Alexander Murmann <am...@apache.org>
Date: Tuesday, July 28, 2020 at 4:34 PM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: [PROPOSAL] Postpone Geode 1.14
Hi all,
As mentioned on the previous discuss thread, I propose to hold off cutting
1.14 until we have shipped 1.13.
Once we have shipped 1.13, we should discuss when we want to cut the 1.14
release. The actual ship date for Geode 1.13 is important information for
that conversation. Thus we cannot have that conversation before then.
Re: [DISCUSS] Geode 1.14
Posted by Owen Nichols <on...@vmware.com>.
If someone wants to propose a list of must-fix Jira tickets before we can cut the branch, I see that as a shift from a time-based to feature-based branch-cut strategy. Might be fun to try?
Given the distributed nature of the Geode community, picking a date and sticking to it allows decentralized decision-making (each contributor can plan on their own what they can finish and/or how they can help get develop as stable as possible by that date).
To answer your question: the current state of develop feels “pretty good” to me. Knowing that only critical fixes will be allowed onto the branch once cut, the question is really about features. It sounds like there is redis work we’d like to ship. Anything else nearly-done we should considering waiting on?
From: Alexander Murmann <am...@vmware.com>
Date: Monday, November 30, 2020 at 11:57 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [DISCUSS] Geode 1.14
Hi all,
Thanks, Owen for reminding us all of this topic!
I wonder how we feel about the state of develop right now. If we cut 1.14 right now, it will make it easier to stabilize and ship it. However, I see 21 open JIRA tickets affecting 1.14.0. It might be better to have an all-hands effort to address as much as possible on develop and then cut 1.14. If we shift all attention to 1.14, develop will likely never get better. I'd love to get closer to an always shippable develop branch. That should vastly reduce future release pain and make everyday development better as well.
Thoughts?
________________________________
From: Jens Deppe <jd...@vmware.com>
Sent: Wednesday, November 25, 2020 20:11
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [DISCUSS] Geode 1.14
Hi Owen,
Thanks for starting this conversation and especially for volunteering as Release Manager!
Since we're already a couple of quarters 'behind', in terms of releases, I'd prefer cutting the 1.14 branch ASAP. Leaving it until Feb means we'll have 9 months of changes to stabilize. How long might that take to finally get shipped? (rhetorical).
--Jens
On 11/25/20, 6:05 PM, "Owen Nichols" <on...@vmware.com> wrote:
The trigger in @Alexander’s July 28 proposal to postpone 1.14 has been met (we shipped 1.13).
It’s time to discuss when we want to cut the 1.14 branch. I will volunteer as Release Manager.
Below are all release dates since Geode adopted a time-based release cadence.
Minor releases:
1.13 branch cut May 4 2020, 1.13.0 shipped Sep 9 2020
1.12 branch cut Feb 4 2020 1.12.0 shipped Mar 31 2020
1.11 branch cut Nov 4 2019 1.11.0 shipped Dec 31 2019
1.10 branch cut Aug 2 2019 1.10.0 shipped Sep 26 2019
1.9 branch cut Feb 19 2019 1.9.0 shipped Apr 24 2019
1.8 branch cut Nov 1 2018 1.8.0 shipped Dec 12 2018
Patch releases:
1.13.1 shipped Nov 18 2020
1.9.2 shipped Nov 14 2019
1.9.1 shipped Sep 6 2019
I’ll toss out an initial suggestion: Let’s cut the support/1.14 branch on the next date in the original quarterly cadence: Feb 1 2021.
-Owen
From: Alexander Murmann <am...@apache.org>
Date: Tuesday, July 28, 2020 at 4:34 PM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: [PROPOSAL] Postpone Geode 1.14
Hi all,
As mentioned on the previous discuss thread, I propose to hold off cutting
1.14 until we have shipped 1.13.
Once we have shipped 1.13, we should discuss when we want to cut the 1.14
release. The actual ship date for Geode 1.13 is important information for
that conversation. Thus we cannot have that conversation before then.
Re: [DISCUSS] Geode 1.14
Posted by Robert Houghton <rh...@vmware.com>.
@alexander, I agree that stabilizing on 1.14 will be much easier to do, than to manage the fixes while develop features move along apace. I disagree that shifting attention to 1.14 will mean that develop does not get better. We can port the fixes forward, just as easily as we backport them. Same effort, but a more-quickly-stable release branch.
-Robert
From: Alexander Murmann <am...@vmware.com>
Date: Monday, November 30, 2020 at 11:57 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [DISCUSS] Geode 1.14
Hi all,
Thanks, Owen for reminding us all of this topic!
I wonder how we feel about the state of develop right now. If we cut 1.14 right now, it will make it easier to stabilize and ship it. However, I see 21 open JIRA tickets affecting 1.14.0. It might be better to have an all-hands effort to address as much as possible on develop and then cut 1.14. If we shift all attention to 1.14, develop will likely never get better. I'd love to get closer to an always shippable develop branch. That should vastly reduce future release pain and make everyday development better as well.
Thoughts?
________________________________
From: Jens Deppe <jd...@vmware.com>
Sent: Wednesday, November 25, 2020 20:11
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [DISCUSS] Geode 1.14
Hi Owen,
Thanks for starting this conversation and especially for volunteering as Release Manager!
Since we're already a couple of quarters 'behind', in terms of releases, I'd prefer cutting the 1.14 branch ASAP. Leaving it until Feb means we'll have 9 months of changes to stabilize. How long might that take to finally get shipped? (rhetorical).
--Jens
On 11/25/20, 6:05 PM, "Owen Nichols" <on...@vmware.com> wrote:
The trigger in @Alexander’s July 28 proposal to postpone 1.14 has been met (we shipped 1.13).
It’s time to discuss when we want to cut the 1.14 branch. I will volunteer as Release Manager.
Below are all release dates since Geode adopted a time-based release cadence.
Minor releases:
1.13 branch cut May 4 2020, 1.13.0 shipped Sep 9 2020
1.12 branch cut Feb 4 2020 1.12.0 shipped Mar 31 2020
1.11 branch cut Nov 4 2019 1.11.0 shipped Dec 31 2019
1.10 branch cut Aug 2 2019 1.10.0 shipped Sep 26 2019
1.9 branch cut Feb 19 2019 1.9.0 shipped Apr 24 2019
1.8 branch cut Nov 1 2018 1.8.0 shipped Dec 12 2018
Patch releases:
1.13.1 shipped Nov 18 2020
1.9.2 shipped Nov 14 2019
1.9.1 shipped Sep 6 2019
I’ll toss out an initial suggestion: Let’s cut the support/1.14 branch on the next date in the original quarterly cadence: Feb 1 2021.
-Owen
From: Alexander Murmann <am...@apache.org>
Date: Tuesday, July 28, 2020 at 4:34 PM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: [PROPOSAL] Postpone Geode 1.14
Hi all,
As mentioned on the previous discuss thread, I propose to hold off cutting
1.14 until we have shipped 1.13.
Once we have shipped 1.13, we should discuss when we want to cut the 1.14
release. The actual ship date for Geode 1.13 is important information for
that conversation. Thus we cannot have that conversation before then.
Re: [DISCUSS] Geode 1.14
Posted by Alexander Murmann <am...@vmware.com>.
Hi all,
Thanks, Owen for reminding us all of this topic!
I wonder how we feel about the state of develop right now. If we cut 1.14 right now, it will make it easier to stabilize and ship it. However, I see 21 open JIRA tickets affecting 1.14.0. It might be better to have an all-hands effort to address as much as possible on develop and then cut 1.14. If we shift all attention to 1.14, develop will likely never get better. I'd love to get closer to an always shippable develop branch. That should vastly reduce future release pain and make everyday development better as well.
Thoughts?
________________________________
From: Jens Deppe <jd...@vmware.com>
Sent: Wednesday, November 25, 2020 20:11
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [DISCUSS] Geode 1.14
Hi Owen,
Thanks for starting this conversation and especially for volunteering as Release Manager!
Since we're already a couple of quarters 'behind', in terms of releases, I'd prefer cutting the 1.14 branch ASAP. Leaving it until Feb means we'll have 9 months of changes to stabilize. How long might that take to finally get shipped? (rhetorical).
--Jens
On 11/25/20, 6:05 PM, "Owen Nichols" <on...@vmware.com> wrote:
The trigger in @Alexander’s July 28 proposal to postpone 1.14 has been met (we shipped 1.13).
It’s time to discuss when we want to cut the 1.14 branch. I will volunteer as Release Manager.
Below are all release dates since Geode adopted a time-based release cadence.
Minor releases:
1.13 branch cut May 4 2020, 1.13.0 shipped Sep 9 2020
1.12 branch cut Feb 4 2020 1.12.0 shipped Mar 31 2020
1.11 branch cut Nov 4 2019 1.11.0 shipped Dec 31 2019
1.10 branch cut Aug 2 2019 1.10.0 shipped Sep 26 2019
1.9 branch cut Feb 19 2019 1.9.0 shipped Apr 24 2019
1.8 branch cut Nov 1 2018 1.8.0 shipped Dec 12 2018
Patch releases:
1.13.1 shipped Nov 18 2020
1.9.2 shipped Nov 14 2019
1.9.1 shipped Sep 6 2019
I’ll toss out an initial suggestion: Let’s cut the support/1.14 branch on the next date in the original quarterly cadence: Feb 1 2021.
-Owen
From: Alexander Murmann <am...@apache.org>
Date: Tuesday, July 28, 2020 at 4:34 PM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: [PROPOSAL] Postpone Geode 1.14
Hi all,
As mentioned on the previous discuss thread, I propose to hold off cutting
1.14 until we have shipped 1.13.
Once we have shipped 1.13, we should discuss when we want to cut the 1.14
release. The actual ship date for Geode 1.13 is important information for
that conversation. Thus we cannot have that conversation before then.
Re: [DISCUSS] Geode 1.14
Posted by Jens Deppe <jd...@vmware.com>.
Hi Owen,
Thanks for starting this conversation and especially for volunteering as Release Manager!
Since we're already a couple of quarters 'behind', in terms of releases, I'd prefer cutting the 1.14 branch ASAP. Leaving it until Feb means we'll have 9 months of changes to stabilize. How long might that take to finally get shipped? (rhetorical).
--Jens
On 11/25/20, 6:05 PM, "Owen Nichols" <on...@vmware.com> wrote:
The trigger in @Alexander’s July 28 proposal to postpone 1.14 has been met (we shipped 1.13).
It’s time to discuss when we want to cut the 1.14 branch. I will volunteer as Release Manager.
Below are all release dates since Geode adopted a time-based release cadence.
Minor releases:
1.13 branch cut May 4 2020, 1.13.0 shipped Sep 9 2020
1.12 branch cut Feb 4 2020 1.12.0 shipped Mar 31 2020
1.11 branch cut Nov 4 2019 1.11.0 shipped Dec 31 2019
1.10 branch cut Aug 2 2019 1.10.0 shipped Sep 26 2019
1.9 branch cut Feb 19 2019 1.9.0 shipped Apr 24 2019
1.8 branch cut Nov 1 2018 1.8.0 shipped Dec 12 2018
Patch releases:
1.13.1 shipped Nov 18 2020
1.9.2 shipped Nov 14 2019
1.9.1 shipped Sep 6 2019
I’ll toss out an initial suggestion: Let’s cut the support/1.14 branch on the next date in the original quarterly cadence: Feb 1 2021.
-Owen
From: Alexander Murmann <am...@apache.org>
Date: Tuesday, July 28, 2020 at 4:34 PM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: [PROPOSAL] Postpone Geode 1.14
Hi all,
As mentioned on the previous discuss thread, I propose to hold off cutting
1.14 until we have shipped 1.13.
Once we have shipped 1.13, we should discuss when we want to cut the 1.14
release. The actual ship date for Geode 1.13 is important information for
that conversation. Thus we cannot have that conversation before then.
[DISCUSS] Geode 1.14
Posted by Owen Nichols <on...@vmware.com>.
The trigger in @Alexander’s July 28 proposal to postpone 1.14 has been met (we shipped 1.13).
It’s time to discuss when we want to cut the 1.14 branch. I will volunteer as Release Manager.
Below are all release dates since Geode adopted a time-based release cadence.
Minor releases:
1.13 branch cut May 4 2020, 1.13.0 shipped Sep 9 2020
1.12 branch cut Feb 4 2020 1.12.0 shipped Mar 31 2020
1.11 branch cut Nov 4 2019 1.11.0 shipped Dec 31 2019
1.10 branch cut Aug 2 2019 1.10.0 shipped Sep 26 2019
1.9 branch cut Feb 19 2019 1.9.0 shipped Apr 24 2019
1.8 branch cut Nov 1 2018 1.8.0 shipped Dec 12 2018
Patch releases:
1.13.1 shipped Nov 18 2020
1.9.2 shipped Nov 14 2019
1.9.1 shipped Sep 6 2019
I’ll toss out an initial suggestion: Let’s cut the support/1.14 branch on the next date in the original quarterly cadence: Feb 1 2021.
-Owen
From: Alexander Murmann <am...@apache.org>
Date: Tuesday, July 28, 2020 at 4:34 PM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: [PROPOSAL] Postpone Geode 1.14
Hi all,
As mentioned on the previous discuss thread, I propose to hold off cutting
1.14 until we have shipped 1.13.
Once we have shipped 1.13, we should discuss when we want to cut the 1.14
release. The actual ship date for Geode 1.13 is important information for
that conversation. Thus we cannot have that conversation before then.
Re: [PROPOSAL] Postpone Geode 1.14
Posted by Darrel Schneider <da...@vmware.com>.
+1
________________________________
From: Alexander Murmann <am...@apache.org>
Sent: Tuesday, July 28, 2020 4:34 PM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: [PROPOSAL] Postpone Geode 1.14
Hi all,
As mentioned on the previous discuss thread, I propose to hold off cutting
1.14 until we have shipped 1.13.
Once we have shipped 1.13, we should discuss when we want to cut the 1.14
release. The actual ship date for Geode 1.13 is important information for
that conversation. Thus we cannot have that conversation before then.
Re: [PROPOSAL] Postpone Geode 1.14
Posted by Dave Barnes <db...@apache.org>.
+1
On Tue, Jul 28, 2020 at 5:05 PM Donal Evans <do...@vmware.com> wrote:
> +1
> ________________________________
> From: Owen Nichols <on...@vmware.com>
> Sent: Tuesday, July 28, 2020 4:38 PM
> To: Alexander Murmann <am...@apache.org>; dev@geode.apache.org <
> dev@geode.apache.org>
> Subject: Re: [PROPOSAL] Postpone Geode 1.14
>
> +1
>
>
> ---
> Sent from Workspace ONE Boxer<
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatisworkspaceone.com%2Fboxer&data=02%7C01%7Cdoevans%40vmware.com%7Ccd4d1f981e344957f92a08d8334f6516%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637315763386093818&sdata=Ydv6m8%2F2p6c342hpTp3HStbMDCqD3M4xJfFLjeMc1ZM%3D&reserved=0
> >
>
> On July 28, 2020 at 4:34:55 PM PDT, Alexander Murmann <am...@apache.org>
> wrote:
> Hi all,
>
> As mentioned on the previous discuss thread, I propose to hold off cutting
> 1.14 until we have shipped 1.13.
>
> Once we have shipped 1.13, we should discuss when we want to cut the 1.14
> release. The actual ship date for Geode 1.13 is important information for
> that conversation. Thus we cannot have that conversation before then.
>
Re: [PROPOSAL] Postpone Geode 1.14
Posted by Donal Evans <do...@vmware.com>.
+1
________________________________
From: Owen Nichols <on...@vmware.com>
Sent: Tuesday, July 28, 2020 4:38 PM
To: Alexander Murmann <am...@apache.org>; dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [PROPOSAL] Postpone Geode 1.14
+1
---
Sent from Workspace ONE Boxer<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatisworkspaceone.com%2Fboxer&data=02%7C01%7Cdoevans%40vmware.com%7Ccd4d1f981e344957f92a08d8334f6516%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637315763386093818&sdata=Ydv6m8%2F2p6c342hpTp3HStbMDCqD3M4xJfFLjeMc1ZM%3D&reserved=0>
On July 28, 2020 at 4:34:55 PM PDT, Alexander Murmann <am...@apache.org> wrote:
Hi all,
As mentioned on the previous discuss thread, I propose to hold off cutting
1.14 until we have shipped 1.13.
Once we have shipped 1.13, we should discuss when we want to cut the 1.14
release. The actual ship date for Geode 1.13 is important information for
that conversation. Thus we cannot have that conversation before then.
Re: [PROPOSAL] Postpone Geode 1.14
Posted by Owen Nichols <on...@vmware.com>.
+1
---
Sent from Workspace ONE Boxer<https://whatisworkspaceone.com/boxer>
On July 28, 2020 at 4:34:55 PM PDT, Alexander Murmann <am...@apache.org> wrote:
Hi all,
As mentioned on the previous discuss thread, I propose to hold off cutting
1.14 until we have shipped 1.13.
Once we have shipped 1.13, we should discuss when we want to cut the 1.14
release. The actual ship date for Geode 1.13 is important information for
that conversation. Thus we cannot have that conversation before then.
Re: [PROPOSAL] Postpone Geode 1.14
Posted by Alexander Murmann <am...@apache.org>.
Mark, that's a great point! I'll give everyone till tomorrow to contribute
their opinion on this thread and then inform the user list.
Thanks!
On Wed, Jul 29, 2020 at 1:35 PM Mark Bretl <mb...@apache.org> wrote:
> +1
>
> Should we need to drop a line to user@geode or is communicating on this
> list enough once decided?
>
> --Mark
>
> On Wed, Jul 29, 2020 at 7:05 AM Joris Melchior <jm...@vmware.com>
> wrote:
>
> > +1
> >
> > On 2020-07-28, 7:34 PM, "Alexander Murmann" <am...@apache.org>
> wrote:
> >
> > Hi all,
> >
> > As mentioned on the previous discuss thread, I propose to hold off
> > cutting
> > 1.14 until we have shipped 1.13.
> >
> > Once we have shipped 1.13, we should discuss when we want to cut the
> > 1.14
> > release. The actual ship date for Geode 1.13 is important information
> > for
> > that conversation. Thus we cannot have that conversation before then.
> >
> >
>
Re: [PROPOSAL] Postpone Geode 1.14
Posted by Owen Nichols <on...@vmware.com>.
Hi Michael, lack of replies may be simply due to not having shipped 1.13 yet. Once it's in the rearview mirror, folks may be more in the frame of mind to look back at it, perhaps as part of the already-proposed discussion ("Once we have shipped 1.13, we should discuss when we want to cut the 1.14").
Traditionally Geode uses the [DISCUSS] email thread format to accommodate our worldwide developer community. Looking forward to hearing your voice (and hopefully many others) soon.
On 8/7/20, 12:00 PM, "Michael Oleske" <mo...@vmware.com> wrote:
I'm going to take the lack of replies as there are no plans for a retrospective on this. If there is interest in doing this in the future, I'd be happy to facilitate the discussion.
-michael
________________________________
From: Mark Hanson <ha...@vmware.com>
Sent: Monday, August 3, 2020 09:59
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [PROPOSAL] Postpone Geode 1.14
+1 to Michael's suggestion.
On 7/31/20, 5:38 PM, "Michael Oleske" <mo...@vmware.com> wrote:
Is there plans as a community to do a postmortem or retrospective around why the release is taking so long? If there is an understanding of events that occurred to cause the long delay of Geode 1.13 to be released, that would help inform decisions if processes should change or if the release cadence should change (or both!)
-michael
________________________________
From: Xiaojian Zhou <zh...@vmware.com>
Sent: Thursday, July 30, 2020 13:47
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [PROPOSAL] Postpone Geode 1.14
+1
On 7/29/20, 1:35 PM, "Mark Bretl" <mb...@apache.org> wrote:
+1
Should we need to drop a line to user@geode or is communicating on this
list enough once decided?
--Mark
On Wed, Jul 29, 2020 at 7:05 AM Joris Melchior <jm...@vmware.com> wrote:
> +1
>
> On 2020-07-28, 7:34 PM, "Alexander Murmann" <am...@apache.org> wrote:
>
> Hi all,
>
> As mentioned on the previous discuss thread, I propose to hold off
> cutting
> 1.14 until we have shipped 1.13.
>
> Once we have shipped 1.13, we should discuss when we want to cut the
> 1.14
> release. The actual ship date for Geode 1.13 is important information
> for
> that conversation. Thus we cannot have that conversation before then.
>
>
Re: [PROPOSAL] Postpone Geode 1.14
Posted by Michael Oleske <mo...@vmware.com>.
I'm going to take the lack of replies as there are no plans for a retrospective on this. If there is interest in doing this in the future, I'd be happy to facilitate the discussion.
-michael
________________________________
From: Mark Hanson <ha...@vmware.com>
Sent: Monday, August 3, 2020 09:59
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [PROPOSAL] Postpone Geode 1.14
+1 to Michael's suggestion.
On 7/31/20, 5:38 PM, "Michael Oleske" <mo...@vmware.com> wrote:
Is there plans as a community to do a postmortem or retrospective around why the release is taking so long? If there is an understanding of events that occurred to cause the long delay of Geode 1.13 to be released, that would help inform decisions if processes should change or if the release cadence should change (or both!)
-michael
________________________________
From: Xiaojian Zhou <zh...@vmware.com>
Sent: Thursday, July 30, 2020 13:47
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [PROPOSAL] Postpone Geode 1.14
+1
On 7/29/20, 1:35 PM, "Mark Bretl" <mb...@apache.org> wrote:
+1
Should we need to drop a line to user@geode or is communicating on this
list enough once decided?
--Mark
On Wed, Jul 29, 2020 at 7:05 AM Joris Melchior <jm...@vmware.com> wrote:
> +1
>
> On 2020-07-28, 7:34 PM, "Alexander Murmann" <am...@apache.org> wrote:
>
> Hi all,
>
> As mentioned on the previous discuss thread, I propose to hold off
> cutting
> 1.14 until we have shipped 1.13.
>
> Once we have shipped 1.13, we should discuss when we want to cut the
> 1.14
> release. The actual ship date for Geode 1.13 is important information
> for
> that conversation. Thus we cannot have that conversation before then.
>
>
Re: [PROPOSAL] Postpone Geode 1.14
Posted by Mark Hanson <ha...@vmware.com>.
+1 to Michael's suggestion.
On 7/31/20, 5:38 PM, "Michael Oleske" <mo...@vmware.com> wrote:
Is there plans as a community to do a postmortem or retrospective around why the release is taking so long? If there is an understanding of events that occurred to cause the long delay of Geode 1.13 to be released, that would help inform decisions if processes should change or if the release cadence should change (or both!)
-michael
________________________________
From: Xiaojian Zhou <zh...@vmware.com>
Sent: Thursday, July 30, 2020 13:47
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [PROPOSAL] Postpone Geode 1.14
+1
On 7/29/20, 1:35 PM, "Mark Bretl" <mb...@apache.org> wrote:
+1
Should we need to drop a line to user@geode or is communicating on this
list enough once decided?
--Mark
On Wed, Jul 29, 2020 at 7:05 AM Joris Melchior <jm...@vmware.com> wrote:
> +1
>
> On 2020-07-28, 7:34 PM, "Alexander Murmann" <am...@apache.org> wrote:
>
> Hi all,
>
> As mentioned on the previous discuss thread, I propose to hold off
> cutting
> 1.14 until we have shipped 1.13.
>
> Once we have shipped 1.13, we should discuss when we want to cut the
> 1.14
> release. The actual ship date for Geode 1.13 is important information
> for
> that conversation. Thus we cannot have that conversation before then.
>
>
Re: [PROPOSAL] Postpone Geode 1.14
Posted by Michael Oleske <mo...@vmware.com>.
Is there plans as a community to do a postmortem or retrospective around why the release is taking so long? If there is an understanding of events that occurred to cause the long delay of Geode 1.13 to be released, that would help inform decisions if processes should change or if the release cadence should change (or both!)
-michael
________________________________
From: Xiaojian Zhou <zh...@vmware.com>
Sent: Thursday, July 30, 2020 13:47
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [PROPOSAL] Postpone Geode 1.14
+1
On 7/29/20, 1:35 PM, "Mark Bretl" <mb...@apache.org> wrote:
+1
Should we need to drop a line to user@geode or is communicating on this
list enough once decided?
--Mark
On Wed, Jul 29, 2020 at 7:05 AM Joris Melchior <jm...@vmware.com> wrote:
> +1
>
> On 2020-07-28, 7:34 PM, "Alexander Murmann" <am...@apache.org> wrote:
>
> Hi all,
>
> As mentioned on the previous discuss thread, I propose to hold off
> cutting
> 1.14 until we have shipped 1.13.
>
> Once we have shipped 1.13, we should discuss when we want to cut the
> 1.14
> release. The actual ship date for Geode 1.13 is important information
> for
> that conversation. Thus we cannot have that conversation before then.
>
>
Re: [PROPOSAL] Postpone Geode 1.14
Posted by Xiaojian Zhou <zh...@vmware.com>.
+1
On 7/29/20, 1:35 PM, "Mark Bretl" <mb...@apache.org> wrote:
+1
Should we need to drop a line to user@geode or is communicating on this
list enough once decided?
--Mark
On Wed, Jul 29, 2020 at 7:05 AM Joris Melchior <jm...@vmware.com> wrote:
> +1
>
> On 2020-07-28, 7:34 PM, "Alexander Murmann" <am...@apache.org> wrote:
>
> Hi all,
>
> As mentioned on the previous discuss thread, I propose to hold off
> cutting
> 1.14 until we have shipped 1.13.
>
> Once we have shipped 1.13, we should discuss when we want to cut the
> 1.14
> release. The actual ship date for Geode 1.13 is important information
> for
> that conversation. Thus we cannot have that conversation before then.
>
>
Re: [PROPOSAL] Postpone Geode 1.14
Posted by Mark Bretl <mb...@apache.org>.
+1
Should we need to drop a line to user@geode or is communicating on this
list enough once decided?
--Mark
On Wed, Jul 29, 2020 at 7:05 AM Joris Melchior <jm...@vmware.com> wrote:
> +1
>
> On 2020-07-28, 7:34 PM, "Alexander Murmann" <am...@apache.org> wrote:
>
> Hi all,
>
> As mentioned on the previous discuss thread, I propose to hold off
> cutting
> 1.14 until we have shipped 1.13.
>
> Once we have shipped 1.13, we should discuss when we want to cut the
> 1.14
> release. The actual ship date for Geode 1.13 is important information
> for
> that conversation. Thus we cannot have that conversation before then.
>
>
Re: [PROPOSAL] Postpone Geode 1.14
Posted by Joris Melchior <jm...@vmware.com>.
+1
On 2020-07-28, 7:34 PM, "Alexander Murmann" <am...@apache.org> wrote:
Hi all,
As mentioned on the previous discuss thread, I propose to hold off cutting
1.14 until we have shipped 1.13.
Once we have shipped 1.13, we should discuss when we want to cut the 1.14
release. The actual ship date for Geode 1.13 is important information for
that conversation. Thus we cannot have that conversation before then.