[FYI] PR checks
Concourse job names have been changed to lowercase for conformity[1]. If your PR shows required checks with a status of "Expected -- Waiting for status to be reported", please push another commit. [1] https://concourse-ci.org/config-basics.html#schema.identifier
Re: [FYI] PR checks
Thanks, Owen. I was sitting down to write this. For more context: With the merge of GEODE-9298 to remove concourse deprecations from our pipeline, many of the concourse jobs have been re-named. This may cause issues with in-flight PRs not correctly updating their status with GitHub, which could lead to the merge button not being enabled for even passing PRs. If this happens to you, please either re-trigger the specific job, or push a new (empty) commit to your PR branch. Thank you, -Robert Houghton From: Owen Nichols Date: Friday, May 28, 2021 at 9:07 AM To: dev@geode.apache.org Subject: [FYI] PR checks Concourse job names have been changed to lowercase for conformity[1]. If your PR shows required checks with a status of "Expected -- Waiting for status to be reported", please push another commit. [1] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse-ci.org%2Fconfig-basics.html%23schema.identifier&data=04%7C01%7Crhoughton%40vmware.com%7Cf857a3a4f6384aae491b08d921f29eed%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637578148215521004%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=R%2FjtMxdWShzwrMbIjEtEA1zozL1XTtwRzDabHS2m3PM%3D&reserved=0
[Discuss] New feature work approval state in Geode project?
Hi All, There has been some discussion about adding a new state of approved to Geode Jira for features or something like it, to help prevent work being done that doesn’t make it into the project. What to people think? Thanks, Mark
Re: [Discuss] New feature work approval state in Geode project?
Hi Mark, Could you explain that a bit more – I’m not clear what you mean by: “to help prevent work being done that doesn’t make it into the project”. Does that mean work that isn’t somehow related to a (new) feature. --Jens From: Mark Hanson Date: Friday, May 28, 2021 at 10:36 AM To: dev@geode.apache.org Subject: [Discuss] New feature work approval state in Geode project? Hi All, There has been some discussion about adding a new state of approved to Geode Jira for features or something like it, to help prevent work being done that doesn’t make it into the project. What to people think? Thanks, Mark
Re: [Discuss] New feature work approval state in Geode project?
Can you provide a more concrete example? I don’t understand why there would be a JIRA written without a reasonable belief it would be executed on. A JIRA that is later determined to not be worth the effort, not a bug, or whatever, should just closed as “won’t fix”. > On May 28, 2021, at 10:36 AM, Mark Hanson wrote: > > Hi All, > > There has been some discussion about adding a new state of approved to Geode > Jira for features or something like it, to help prevent work being done that > doesn’t make it into the project. What to people think? > > Thanks, > Mark
Re: [Discuss] New feature work approval state in Geode project?
Oh, I see now. Yes, +1 to what Jake said. From: Jacob Barrett Date: Friday, May 28, 2021 at 10:41 AM To: dev@geode.apache.org Subject: Re: [Discuss] New feature work approval state in Geode project? Can you provide a more concrete example? I don’t understand why there would be a JIRA written without a reasonable belief it would be executed on. A JIRA that is later determined to not be worth the effort, not a bug, or whatever, should just closed as “won’t fix”. > On May 28, 2021, at 10:36 AM, Mark Hanson wrote: > > Hi All, > > There has been some discussion about adding a new state of approved to Geode > Jira for features or something like it, to help prevent work being done that > doesn’t make it into the project. What to people think? > > Thanks, > Mark
Re: [Discuss] New feature work approval state in Geode project?
Does this mean that a Jira would have to be approved before assigned? Dale From: Mark Hanson Date: Friday, May 28, 2021 at 10:36 AM To: dev@geode.apache.org Subject: [Discuss] New feature work approval state in Geode project? Hi All, There has been some discussion about adding a new state of approved to Geode Jira for features or something like it, to help prevent work being done that doesn’t make it into the project. What to people think? Thanks, Mark
Re: [Discuss] New feature work approval state in Geode project?
Can you be more elaborate on this... Are we saying; if I (geode dev) find a bug or feature that I need for my application, I need to get approval to create a ticket and work on it? We already have RFC process, won't that suffice... -Anil. On 5/28/21, 10:36 AM, "Mark Hanson" wrote: Hi All, There has been some discussion about adding a new state of approved to Geode Jira for features or something like it, to help prevent work being done that doesn’t make it into the project. What to people think? Thanks, Mark
Re: [Discuss] New feature work approval state in Geode project?
Hi All, I am just starting the chain to get it into the dev list. Bill and Donal had more concrete ideas to share. For the record, I am happy with the RFC process, but I am flexible. Thanks, Mark On 5/28/21, 10:43 AM, "Anilkumar Gingade" wrote: Can you be more elaborate on this... Are we saying; if I (geode dev) find a bug or feature that I need for my application, I need to get approval to create a ticket and work on it? We already have RFC process, won't that suffice... -Anil. On 5/28/21, 10:36 AM, "Mark Hanson" wrote: Hi All, There has been some discussion about adding a new state of approved to Geode Jira for features or something like it, to help prevent work being done that doesn’t make it into the project. What to people think? Thanks, Mark
Re: [Discuss] New feature work approval state in Geode project?
We have an RFC process "to get to consensus faster and ultimately get to execution faster". But I think in general folks tend to only do an RFC for a "big" change. Bug tickets, and particularly feature tickets are left as a gray area. A google search for "most successful open source project" lists Apache Cassandra at the top. When a bug is submitted to the Cassandra Jira it starts in the TRIAGE NEEDED state. Ostensibly after triage, it moves to the OPEN state which is described as: | "the issue is open and ready for the assignee to start work on it." I think introducing a starting state like TRIAGE NEEDED in the Geode Jira system, and instituting a (gating) triage process would be a good way to keep the Geode architecture cohesive and also to maximize the impact of our contributor's efforts. Perhaps that triage process would be run by code owners in the area(s) affected by the ticket (bug or feature). -Bill On Fri, May 28, 2021 at 10:36 AM Mark Hanson wrote: > Hi All, > > There has been some discussion about adding a new state of approved to > Geode Jira for features or something like it, to help prevent work being > done that doesn’t make it into the project. What to people think? > > Thanks, > Mark >
Re: [Discuss] New feature work approval state in Geode project?
I've also seen this on other projects where sometimes an issue gets substantial support, but ultimately gets rejected because it doesn't match the project's direction. Making this clear before work happens makes sense to me in general. However, I wonder if the additional process in our case is more expensive than the problem we are solving. How often does it happen on Geode that we reject a smaller effort, that wouldn't warrant a RFC, after the work has been done? From: Bill Burcham Sent: Friday, May 28, 2021 10:48 To: dev@geode.apache.org Subject: Re: [Discuss] New feature work approval state in Geode project? We have an RFC process "to get to consensus faster and ultimately get to execution faster". But I think in general folks tend to only do an RFC for a "big" change. Bug tickets, and particularly feature tickets are left as a gray area. A google search for "most successful open source project" lists Apache Cassandra at the top. When a bug is submitted to the Cassandra Jira it starts in the TRIAGE NEEDED state. Ostensibly after triage, it moves to the OPEN state which is described as: | "the issue is open and ready for the assignee to start work on it." I think introducing a starting state like TRIAGE NEEDED in the Geode Jira system, and instituting a (gating) triage process would be a good way to keep the Geode architecture cohesive and also to maximize the impact of our contributor's efforts. Perhaps that triage process would be run by code owners in the area(s) affected by the ticket (bug or feature). -Bill On Fri, May 28, 2021 at 10:36 AM Mark Hanson wrote: > Hi All, > > There has been some discussion about adding a new state of approved to > Geode Jira for features or something like it, to help prevent work being > done that doesn’t make it into the project. What to people think? > > Thanks, > Mark >
Re: [Discuss] New feature work approval state in Geode project?
> On May 28, 2021, at 10:48 AM, Bill Burcham wrote: > > A google search for "most successful open source project" lists Apache > Cassandra at the top. When a bug is submitted to the Cassandra Jira it > starts in the TRIAGE NEEDED state. Ostensibly after triage, it moves to the > OPEN state which is described as: > > | "the issue is open and ready for the assignee to start work on it." > > I think introducing a starting state like TRIAGE NEEDED in the Geode Jira > system, and instituting a (gating) triage process would be a good way to > keep the Geode architecture cohesive and also to maximize the impact of our > contributor's efforts. I think this is very different from what this thread was initially asking for. An “approved” state is very different in my book than a bug needing more info, “triage” state. I would definitely agree with this change to add a “needs info”/“triage” state to bugs. It fits my previous statement that a ticket is opened when there is reasonable belief work needs to be done. In this case the initial work is to fully understand the issue. The next step is to progress to fixing or closed. -Jake
Re: [Discuss] New feature work approval state in Geode project?
I think the key difference between what Bill and Jake are saying is that Bill is saying a new feature needs approval in a more structured way. I think Bill's process is open the jira, then it is "approved" or "won't do" then work starts. I think what Jake is saying is a little less structured. That may be my reading though. On 5/28/21, 11:14 AM, "Jacob Barrett" wrote: > On May 28, 2021, at 10:48 AM, Bill Burcham wrote: > > A google search for "most successful open source project" lists Apache > Cassandra at the top. When a bug is submitted to the Cassandra Jira it > starts in the TRIAGE NEEDED state. Ostensibly after triage, it moves to the > OPEN state which is described as: > > | "the issue is open and ready for the assignee to start work on it." > > I think introducing a starting state like TRIAGE NEEDED in the Geode Jira > system, and instituting a (gating) triage process would be a good way to > keep the Geode architecture cohesive and also to maximize the impact of our > contributor's efforts. I think this is very different from what this thread was initially asking for. An “approved” state is very different in my book than a bug needing more info, “triage” state. I would definitely agree with this change to add a “needs info”/“triage” state to bugs. It fits my previous statement that a ticket is opened when there is reasonable belief work needs to be done. In this case the initial work is to fully understand the issue. The next step is to progress to fixing or closed. -Jake
Re: [Discuss] New feature work approval state in Geode project?
> On May 28, 2021, at 11:24 AM, Mark Hanson wrote: > > I think the key difference between what Bill and Jake are saying is that Bill > is saying a new feature needs approval in a more structured way. I think > Bill's process is open the jira, then it is "approved" or "won't do" then > work starts. I think what Jake is saying is a little less structured. That > may be my reading though. The difference is between bugs vs features. We have a process for features, lazy consensus on RFCs. We have a process for minor features/improvements/tasks, greedy concensus on PR approvals. -Jake
Re: [Discuss] New feature work approval state in Geode project?
My thoughts; I can't make distinction between feature or bug; it’s a change to the codebase, if it has greater impact, is sensitive and takes time to build; then it is a candidate to bring it up and talk about it before implementation. Sometime its hard to determine/distinguish it, we developer should make a good judgement of it and be open for any suggestion. Currently we have a RFC process; adding more process/steps adds additional onus; we can tweak RFC process or replace it with better option but let's keep it simple/minimal. On 5/28/21, 11:57 AM, "Jacob Barrett" wrote: > On May 28, 2021, at 11:24 AM, Mark Hanson wrote: > > I think the key difference between what Bill and Jake are saying is that Bill is saying a new feature needs approval in a more structured way. I think Bill's process is open the jira, then it is "approved" or "won't do" then work starts. I think what Jake is saying is a little less structured. That may be my reading though. The difference is between bugs vs features. We have a process for features, lazy consensus on RFCs. We have a process for minor features/improvements/tasks, greedy concensus on PR approvals. -Jake
Re: [Discuss] New feature work approval state in Geode project?
I think the main problem this discussion thread could solve is when a developer files a Jira ticket as a bug, assigns it to themselves, and begins work on it. After some time (possibly even a month or something significant like that), they submit a PR to fix the ticket, only to find out from multiple reviewers that the community believes it is not a bug and rejects the PR while declaring that the bug isn't even a bug. The ticket is then closed as "will not fix" and the contributor is thoroughly demoralized (I would be). This community does seem to be lacking any sort of process for reviewing and triaging bugs unless the filer of the ticket were to discuss it on the dev-list after filing it but before coding starts. So, for bugs, this community could recommend optional discussion of newly filed bugs on the dev-list before beginning work on it to ensure that the majority don’t later disagree that it’s a bug during PR review. This would save the contributor a lot of wasted effort, or they might even be able to convince others that it is indeed a bug before starting work on it. -Kirk On Fri, May 28, 2021 at 11:14 AM Jacob Barrett wrote: > > > > On May 28, 2021, at 10:48 AM, Bill Burcham > wrote: > > > > A google search for "most successful open source project" lists Apache > > Cassandra at the top. When a bug is submitted to the Cassandra Jira it > > starts in the TRIAGE NEEDED state. Ostensibly after triage, it moves to > the > > OPEN state which is described as: > > > > | "the issue is open and ready for the assignee to start work on it." > > > > I think introducing a starting state like TRIAGE NEEDED in the Geode Jira > > system, and instituting a (gating) triage process would be a good way to > > keep the Geode architecture cohesive and also to maximize the impact of > our > > contributor's efforts. > > > I think this is very different from what this thread was initially asking > for. An “approved” state is very different in my book than a bug needing > more info, “triage” state. I would definitely agree with this change to add > a “needs info”/“triage” state to bugs. It fits my previous statement that a > ticket is opened when there is reasonable belief work needs to be done. In > this case the initial work is to fully understand the issue. The next step > is to progress to fixing or closed. > > -Jake > >
Re: Cleaning up the codebase - use curly braces everywhere
+1 Also, I think if the entire work is done by IntelliJ then just mention that in the PR description and I'm happy to add approval without stepping through every line. I'd probably just pick a dozen random ones to check and then approve it. On Thu, May 27, 2021 at 6:36 PM Darrel Schneider wrote: > +1 thanks for working on this > > From: Donal Evans > Sent: Thursday, May 27, 2021 10:22 AM > To: dev@geode.apache.org > Subject: Cleaning up the codebase - use curly braces everywhere > > Hi Geode dev, > > I've recently been looking at ways to improve code quality in small ways > throughout the codebase, and as a starting point, I thought it would be > good to make it so that we're consistently using curly braces for control > flow statements everywhere, since this is something that's specifically > called out in the Geode Code Style Guide wiki page[1] as one of the "more > important points" of our code style. > > IntelliJ has a "Run inspection by name..." feature that makes it possible > to identify all places where curly braces aren't used for control flow > statements, (which showed over 3300 occurrences in the codebase) and also > allows them to be automatically inserted, making the fix relatively > trivial. Since this PR will touch 640 files, I wanted to make sure to first > check that this is something even worth doing, and, if there's agreement > that it is, to give reviewers context on what the changes are, the > motivation for them, and how they were made, to help with the review > process. > > The draft PR I have up[2] currently has no failing tests and can be marked > as ready to review if there aren't any objections, and once it is, I'll try > to coordinate with codeowners to get the minimal number of approvals > required for a merge (it looks like only 6-7 reviewers are needed, though > I'm sure that almost every code owner will be tagged as reviewers given the > number of files touched). > > If this idea is a success, I think it would be good to have a discussion > about other low-hanging code improvements we could make using static > analysis (unnecessary casts, unused variables, duplicate conditions etc.), > and, once a particular inspection has been "fixed," possibly consider > adding a check for it as part of the PR pre-checkin to make sure it's not > reintroduced. All thoughts and feedback are very welcome. > > Donal > > [1] > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FCode%2BStyle%2BGuide&data=04%7C01%7Cdarrel%40vmware.com%7C55c1f47da50548d3fa5708d92134034c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637577329548326057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BVvzQAdQ24ZuoOdoMrkGNJShmTkep4BGFduSAQu5H6o%3D&reserved=0 > [2] > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F6523&data=04%7C01%7Cdarrel%40vmware.com%7C55c1f47da50548d3fa5708d92134034c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637577329548326057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gzta%2FwrhapOzp0DKcMEn1IR5XsNboWuMlUJwUwOrcGc%3D&reserved=0 >
Re: [Discuss] New feature work approval state in Geode project?
Another thought I have is that if the "fix" for a bug will require any sort of new User API or configuration properties (ie gemfire.properties), then we should always treat that as a new feature that requires going through our RFC process for a new feature. On Fri, May 28, 2021 at 2:42 PM Kirk Lund wrote: > I think the main problem this discussion thread could solve is when a > developer files a Jira ticket as a bug, assigns it to themselves, and > begins work on it. After some time (possibly even a month or something > significant like that), they submit a PR to fix the ticket, only to find > out from multiple reviewers that the community believes it is not a bug and > rejects the PR while declaring that the bug isn't even a bug. The ticket is > then closed as "will not fix" and the contributor is thoroughly demoralized > (I would be). > > This community does seem to be lacking any sort of process for reviewing > and triaging bugs unless the filer of the ticket were to discuss it on the > dev-list after filing it but before coding starts. > > So, for bugs, this community could recommend optional discussion of > newly filed bugs on the dev-list before beginning work on it to ensure that > the majority don’t later disagree that it’s a bug during PR review. This > would save the contributor a lot of wasted effort, or they might even be > able to convince others that it is indeed a bug before starting work on it. > > -Kirk > > On Fri, May 28, 2021 at 11:14 AM Jacob Barrett > wrote: > >> >> >> > On May 28, 2021, at 10:48 AM, Bill Burcham >> wrote: >> > >> > A google search for "most successful open source project" lists Apache >> > Cassandra at the top. When a bug is submitted to the Cassandra Jira it >> > starts in the TRIAGE NEEDED state. Ostensibly after triage, it moves to >> the >> > OPEN state which is described as: >> > >> > | "the issue is open and ready for the assignee to start work on it." >> > >> > I think introducing a starting state like TRIAGE NEEDED in the Geode >> Jira >> > system, and instituting a (gating) triage process would be a good way to >> > keep the Geode architecture cohesive and also to maximize the impact of >> our >> > contributor's efforts. >> >> >> I think this is very different from what this thread was initially asking >> for. An “approved” state is very different in my book than a bug needing >> more info, “triage” state. I would definitely agree with this change to add >> a “needs info”/“triage” state to bugs. It fits my previous statement that a >> ticket is opened when there is reasonable belief work needs to be done. In >> this case the initial work is to fully understand the issue. The next step >> is to progress to fixing or closed. >> >> -Jake >> >>
Re: [Discuss] New feature work approval state in Geode project?
Anil's thoughts parallel what I was trying to describe as well... On Fri, May 28, 2021 at 2:35 PM Anilkumar Gingade wrote: > My thoughts; I can't make distinction between feature or bug; it’s a > change to the codebase, if it has greater impact, is sensitive and takes > time to build; then it is a candidate to bring it up and talk about it > before implementation. Sometime its hard to determine/distinguish it, we > developer should make a good judgement of it and be open for any > suggestion. Currently we have a RFC process; adding more process/steps adds > additional onus; we can tweak RFC process or replace it with better option > but let's keep it simple/minimal. > > > On 5/28/21, 11:57 AM, "Jacob Barrett" wrote: > > > > > On May 28, 2021, at 11:24 AM, Mark Hanson > wrote: > > > > I think the key difference between what Bill and Jake are saying is > that Bill is saying a new feature needs approval in a more structured way. > I think Bill's process is open the jira, then it is "approved" or "won't > do" then work starts. I think what Jake is saying is a little less > structured. That may be my reading though. > > The difference is between bugs vs features. We have a process for > features, lazy consensus on RFCs. We have a process for minor > features/improvements/tasks, greedy concensus on PR approvals. > > -Jake > > >
Re: [Discuss] New feature work approval state in Geode project?
> On May 28, 2021, at 3:45 PM, Kirk Lund wrote: > > Another thought I have is that if the "fix" for a bug will require any sort > of new User API or configuration properties (ie gemfire.properties), then > we should always treat that as a new feature that requires going through > our RFC process for a new feature. I think this is a good distinction of when a bug fix really becomes something different. -Jake
