I STRONGLY AGREE with avoiding Jira ticket numbers in code comments.
In an open-source system, code comments function as user-visible
documentation (whether or not they're flagged for inclusion in the
Javadocs), so rather than resorting to a ticket number in place of an
explanation, provide the exp
+1
In theory, every commit is now associated with a GEODE jira ticket, so leaving
a comment in the code when putting in a fix saying that it's for that ticket is
redundant. Good commit names and messages would provide the broader context for
changes, and regular comments that don't refer to a t
I will handle the PR and merge into support/1.14
Thank you Darrel,
Regards
Nabarun
From: Darrel Schneider
Sent: Tuesday, March 30, 2021 1:49 PM
To: dev@geode.apache.org
Subject: [Proposal] backport GEODE-8761 to support/1.14
The previous fix for GEODE-8761 that
+1
I am pretty sure we had this discussion a long time ago and agreed to it. I
can’t view the archives though since it appears markmail doesn’t like newer
versions of Chrome or Safari.
-Jake
> On Mar 30, 2021, at 2:24 PM, Hale Bales wrote:
>
> Hi all,
>
> I have noticed in the past that the
Hi all,
I have noticed in the past that there are a lot of ticket numbers in the code
(along the lines of "fixes #") that reference tickets in a system that very few
people still have access to. Since the average Geode developer does not have
access to this system, having these in the code does
The previous fix for GEODE-8761 that was backported to support/1.14 had a
problem.
So I'd like to backport the fix for it that can be found in this pull request:
https://github.com/apache/geode/pull/6236
-1 for plugins
+1 for deletion.
I think we should make an effort to document our existing protocol before we
bother worrying about supporting a second one. Blake and I have a Wireshark
filter that is the tiniest step in that direction in one sense. I think taking
larger steps in that direction
The Apache Geode community is pleased to announce the availability of
Apache Geode 1.13.2.
Apache Geode is a data management platform that provides a database-like
consistency model, reliable transaction processing and a shared-nothing
architecture to maintain very low latency performance with hig
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 to communicate with core geode
th
Thanks for calling this out, Bruce!
Even ignoring the curtesy to reviewers, it's hugely beneficial to have at least
descriptive commit messages, that describe the intent behind the change and
maybe even give a little bit of insight into the design decision. JIRA is
great, but all our IDEs and C
+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
I say delete it so you can move forward. If someone wants it in a subproject
repo bad enough they can pull it from the previous commit. It is source control
after all so it never really goes away.
-Jake
> On Mar 30, 2021, at 8:01 AM, Bruce Schuchardt wrote:
>
> Does anyone want to take on th
If you want people to review your PR it would be kind of you to put in a
description of its purpose. If you just reference a JIRA ticket we have to do
the extra work of pulling up the ticket to see what it’s about. I’m seeing
this more and more lately.
Does anyone want to take on the work of moving these sub-projects to another
repository? I picked up the ticket because it's costing us development and
testing time but am not interested in being the owner of it in some other repo.
On 3/30/21, 5:45 AM, "Joris Melchior" wrote:
+1 On this
+1 On this approach. If we could somehow have side project to implement this I
think it would be really helpful.
I also think it's less intimidating to contribute to for a lot of people.
Joris
On 2021-03-29, 2:55 PM, "John Blum" wrote:
How hard is it to put the work like Protobuf in a s
15 matches
Mail list logo
