Re: Cleaning up the codebase - use curly braces everywhere
Given the positive response to this idea, I'm going to mark the PR as ready for review and contact the code owners required to get it merged. Thanks for all the feedback, and hopefully this can be the first step towards a concerted clean-up effort. Donal From: Kirk Lund Sent: Friday, May 28, 2021 3:19 PM To: dev@geode.apache.org Subject: 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%2BGuidedata=04%7C01%7Cdoevans%40vmware.com%7C6d413e51e7814ee308d92226b180%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637578371864383775%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=4An8MCpjP60dPIt%2BXbkmplHh6F8pc%2F0KdpTPO2KnvNI%3Dreserved=0 > [2] > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F6523data=04%7C01%7Cdoevans%40vmware.com%7C6d413e51e7814ee308d92226b180%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637578371864383775%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=pufQ770JEdbJ%2FfWgT0rqQmrLJyFqQQjFc98Q%2FkYnHq4%3Dreserved=0 >
Re: [INFO] Apache Geode 1.14.0 Release Manager
Hi Alberto, For releasing 1.14 we are waiting on two more backports. GEODE-8609 - DUnit runners were not checking the logs for suspicious errors/fatal messages in VMs that were being restarted in a test. A fix is ready and is in PR review stage[1] GEODE-9289 - A problem with Cluster Configuration where a new locator sends its configuration to an old locator, the old locator is unable to deserialize it, causes NPEs and clears out certain fields in the configuration. A PR is ready and is in review phase but this will need GEODE-8609 checked in first.[2] Once these two PRs are merged and backported, we are going to start the process for voting on the release branch and release candidates. My personal estimate is that we can start with the voting process within next week, if we do not detect any serious issues. Please do reach out if you require any additional information. Regards, Nabarun [1] https://github.com/apache/geode/pull/6526 [2] https://github.com/apache/geode/pull/6495 From: Alberto Gomez Sent: Monday, May 31, 2021 8:08 AM To: dev@geode.apache.org Subject: Re: [INFO] Apache Geode 1.14.0 Release Manager Hi Naba, Can you please provide some information about how the 1.14 release is going and if is there any planned date for it? Thanks in advance, Alberto From: Nabarun Nag Sent: Monday, March 22, 2021 5:27 PM To: dev@geode.apache.org Subject: [INFO] Apache Geode 1.14.0 Release Manager Hi everyone, I hope you all are doing well. This is to inform the Apache Geode community that I will be volunteering as the Release Manager for 1.14.0 release. Thank you, Owen, for all the work that has been done to get the release to this point. As for backporting, as a developer, you just need to create a PR against the support/1.14 branch, and you are done. As a release manager, I will take over from there. Just ensure the following: * The PR is a cherry-pick (cherry-pick -x) of a commit that is already in develop * Ensure that there are no merge conflicts. Regards Nabarun Nag
Re: [NOTICE] Git web site publishing to be done via .asf.yaml only as of July 1st
We're on the green list -- we've been compliant since Oct 2019. On Mon, May 31, 2021 at 8:08 AM Anthony Baker wrote: > I believe we will need to update the geode-site repo. > > > Begin forwarded message: > > From: Daniel Gruno > Date: May 31, 2021 at 7:41:05 AM MDT > To: Users > Subject: [NOTICE] Git web site publishing to be done via .asf.yaml only as > of July 1st > Reply-To: priv...@geode.apache.org > > TL;DR: if your project web site is kept in subversion, disregard this > email please. If your project web site is using git, and you have not > deployed it via .asf.yaml, you MUST switch before July 1st or risk your web > site goes stale. > > > > Dear Apache projects, > In order to simplify our web site publishing services and improve > self-serve for projects and stability of deployments, we will be turning > off the old 'gitwcsub' method of publishing git web sites. As of this > moment, this involves 120 web sites. All web sites should switch to our > self-serve method of publishing via the .asf.yaml meta-file. We aim to turn > off gitwcsub around July 1st. > > > ## How to publish via .asf.yaml: > Publishing via .asf.yaml is described at: > https://s.apache.org/asfyamlpublishing > You can also see an example .asf.yaml with publishing and staging profiles > for our own infra web site at: > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Finfrastructure-website%2Fblob%2Fasf-site%2F.asf.yamldata=04%7C01%7Cbakera%40vmware.com%7C3c9e5ce4e2b04461fb5a08d92439bc68%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637580652653660482%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=8rmWnJv6TUUJ1CnHboqk5bOhb0YrObQN3Kfq3JESq34%3Dreserved=0 > > In short, one puts a file called .asf.yaml into the branch that needs to > be published as the project's web site, with the following two-line > content, in this case assuming the published branch is 'asf-site': > > publish: > whoami: asf-site > > > It is important to note that the .asf.yaml file MUST be present at the > root of the file system in the branch you wish to publish. The 'whoami' > parameter acts as a guard, ensure that only the intended branch is used for > publishing. > > > ## Is my project affected by this? > The quickest way to check if you need to switch to a .asf.yaml approach is > to check out site source page at > https://infra-reports.apache.org/site-source/ - if your site is listed in > yellow, you will need to switch. This page will also tell you which branch > you are currently publishing as your web site. This is (should be) the > branch that you must add a .asf.yaml meta file to. > > The web site source list updates every hour. If your project site appears > in green, you are already using .asf.yaml for publishing and do not need to > make any changes. > > > ## What happens if we miss the deadline? > If you miss the deadline, don't fret. Your site will of course still > remain online as is, but new updates will not appear till you create/edit > the .asf.yaml and set up publishing. > > > ## Who do we contact if we have questions? > Please contact us at us...@infra.apache.org if you have any additional > questions. > > > With regards, > Daniel on behalf of ASF Infra. >
