Done!
On Thu, Aug 15, 2019 at 3:21 PM Dan Smith wrote:
> @kirk - go ahead and push it.
>
> -Dan
>
> On Thu, Aug 15, 2019 at 3:13 PM Kirk Lund wrote:
>
> > I have the cherry-pick ready to push or file a PR. Let me know what you
> > prefer...
> >
> > On Thu, Aug 15, 2019 at 3:01 PM Dan Smith wro
@kirk - go ahead and push it.
-Dan
On Thu, Aug 15, 2019 at 3:13 PM Kirk Lund wrote:
> I have the cherry-pick ready to push or file a PR. Let me know what you
> prefer...
>
> On Thu, Aug 15, 2019 at 3:01 PM Dan Smith wrote:
>
> > Normally cherry-picking to the release branch is the release mana
I have the cherry-pick ready to push or file a PR. Let me know what you
prefer...
On Thu, Aug 15, 2019 at 3:01 PM Dan Smith wrote:
> Normally cherry-picking to the release branch is the release managers job
> (Dick in this case) [1]. He asked me to help out while he was on vacation,
> so I will
Normally cherry-picking to the release branch is the release managers job
(Dick in this case) [1]. He asked me to help out while he was on vacation,
so I will go ahead and cherry-pick it over.
I kinda like the process Jake proposed though - creating a PR against the
release branch. My only concern
You should be able to do the cherry-pick on your fork and then open a PR
against the release branch.
> On Aug 15, 2019, at 2:04 PM, Aaron Lindsey wrote:
>
> It sounds like there is consensus on adding this fix. Could someone please
> cherry-pick this for me?
>
> Thanks,
> Aaron
>
>> On Aug 1
It sounds like there is consensus on adding this fix. Could someone please
cherry-pick this for me?
Thanks,
Aaron
> On Aug 14, 2019, at 1:13 PM, Udo Kohlmeyer wrote:
>
> @Aaron,Kirk - thank you for the clarification.
>
> +1 to include the fix, as reverting GEODE-7001 would be more effort :)
>
@Aaron,Kirk - thank you for the clarification.
+1 to include the fix, as reverting GEODE-7001 would be more effort :)
--Udo
On 8/14/19 9:25 AM, Aaron Lindsey wrote:
@Udo, I think Kirk explained it well — This issue was introduced very recently
(right before we cut the release branch) and it h
@Udo, I think Kirk explained it well — This issue was introduced very recently
(right before we cut the release branch) and it has serious consequences
(requires restarting the server).
- Aaron
> On Aug 14, 2019, at 9:06 AM, Kirk Lund wrote:
>
> +1 to include this fix in 1.10.0
>
> FYI: The
+1 to include the fix
> On Aug 14, 2019, at 9:06 AM, Kirk Lund wrote:
>
> +1 to include this fix in 1.10.0
>
> FYI: The race condition for this code path to throw NPE (which is
> catastrophic and requires restarting the server) was introduced by commit
> 279fa0 on July 31 for GEODE-7001.
>
> O
+1 to include this fix in 1.10.0
FYI: The race condition for this code path to throw NPE (which is
catastrophic and requires restarting the server) was introduced by commit
279fa0 on July 31 for GEODE-7001.
On Tue, Aug 13, 2019 at 6:22 PM Anthony Baker wrote:
> Given that we’re trying to stabil
Given that we’re trying to stabilize the release branch and this fix seems to
*help* that I’m in favor of merging it.
Anthony
> On Aug 13, 2019, at 5:32 PM, Udo Kohlmeyer wrote:
>
> @Aaron, is this an existing issue (i.e this was not introduced in a current
> refactor)?
>
> If the answer is
Hi Aaron, thank you for bringing your request and concern.
Geode's release process dictates a time-based schedule to cut release
branches. Once cut, the “critical fixes” rule does allow those to be
brought
to the release branch by proposal on the dev list.
If there is consensus from the Geode c
@Aaron, is this an existing issue (i.e this was not introduced in a
current refactor)?
If the answer is anything other that "This will make the system stop
working", I would vote: -1
If this is an existing issue and has been around for a while, I think we
hold off including this.
I think t
13 matches
Mail list logo
