For clarity- this was +1 to the ides of separate repos for non-core components
On 3/30/21, 11:15 AM, "John Hutchison" wrote:
+1
I think that if we had strongly supported set of "contracts" (apis) that
core Geode provided for "bolt ons" or plugins
+1
I think that if we had strongly supported set of "contracts" (apis) that core
Geode provided for "bolt ons" or plugins to communicate with core geode
through, it would allow us to isolate a lot of the more complicated parts of
the system (core geode) from the logic in the plugins and it m
Hi All-
Prosing to include GEODE-9001 in the 1.14 release.
Rationale for proposal:
This story changes only documentation related files, and only files within the
Geode-Redis module.
This story will provided updated documentation to reflect the most recent
changes in the Geode-Redis module that
Hi all,
Proposal to backport GEODE-8938.
Rationale:
GEODE-8864, which has previously been approved to be backported (and is marked
as a release-blocker) relies on GEODE-8938. GEODE-8938 is small, does not
alter any feature code, and exists entirely within the compatible-with-Redis
area of the
Hi all,
I’m proposing to backport compatibility with Redis HSCAN command to 1.14.
This functionality does not rely on code changes outside of the Geode-Redis
module, and would allow for support for all Hash-related commands in the
compatible-with-Redis section of Geode.
Thanks,
John
endency in this way might be easy to diagnose it
would still be awesome if we could prevent a potential failure ahead of time.
From: John Hutchison
Sent: Tuesday, January 12, 2021 7:57 AM
To: dev@geode.apache.org
Subject: Re: [DISCUSSION] Sho
Hey Sarah
Is there any downside to backporting it?
Does the missing dependency seem like something that would be easily diagnosed
if a minor version is created in the future? Or does it seem like backporting
it now would potentially save people hours of work later on?
-John
On 1/11/21,
Is there some kind linting that we could put into spotless (or a linting tool
that’s run before spotless) to prevent this kind of thing (check against
known proprietary names and derivatives before being allowed through ci)?
From: Jacob Barrett
Date: Tuesday, December 29, 2020 at 1:08 PM
To:
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 devel
Hi Anish-
I believe you would need to create a pull request to have your changes merged
into the main repo.
I’m not sure about the Jira issue.
-John
From: aashish choudhary
Date: Wednesday, November 18, 2020 at 1:55 PM
To: dev@geode.apache.org
Subject: needs permission to push code to geode
thx
From: Dan Smith
Date: Wednesday, November 18, 2020 at 2:08 PM
To: dev@geode.apache.org
Subject: Re: Request for Jira Permissions
Done. You should have access now.
-Dan
From: John Hutchison
Sent: Wednesday, November 18, 2020 11:00 AM
To: dev
Hi,
I’d like to request permission to assign jira tickets to myself and also to
reopen tickets that have been resolved.
Thanks,
John
12 matches
Mail list logo
