[DISCUSS] Monthly, synchronous community meetings

[Alexander Murmann]

Hi everyone,

On occasion we see discussions on PRs, here on the mailing list that might be 
move much quicker if we chatted synchronously about some of these topics and 
then shared the meetings notes back to the mailing list. Of course, our usual 
processes for voting and additional discussions would still need to be just as 
accessible as they are right now on the mailing list to anyone who cannot 
attend a meeting. However, it might allow us to move these discussions along 
faster and also create a stronger sense of community.

I've seen similar things done in Kubernetes Special Interest Groups 
(example)

Meeting Specifics
Frequency: monthly
Time: It seems like most of our community is distributed between Europe and the 
US. 3pm/15:00 UTC (11amEDT/8amPST/17:00 CEST) seems like a good compromise.
How: We'd have a Confluence page to gather topics ahead of time. Topics should 
be added with as much lead time as possible, to allow interested community 
members to plan attendance. We'd use the same page to take meeting notes.
Topic examples: RFC discussions, process proposals (like the recent codeowner 
introduction), show & tells of recent changes, controversial PRs, the sky is 
the limit till we find certain topics are better in a dedicated meeting.

As with everything, I'd expect us to iterate and evolve this

Does this sound valuable to everyone? How could this be better?

Upcoming upgrade to Gradle 6.8.3

[Dale Emery]

On Monday I will merge GEODE-8899 (https://github.com/apache/geode/pull/6280), 
which upgrades the Geode build to use Gradle 6.8.3 (from the current Gradle 
5.5). This has implications for IntelliJ IDEA and for running tests with 
parallelDunit. The implications are minor, but you’ll probably be affected by 
at least the IntelliJ ones. See below for details.

IntelliJ IDEA. Once I merge this upgrade, IntelliJ IDEA may initially become 
confused. If that happens, you will likely need to do one or more of:

  *   Invalidate IntelliJ IDEA’s caches

 *   Select File > Invalidate Caches / Restart…
 *   Select Invalidate and Restart

  *   Re-import Geode into IntelliJ IDEA. See the instructions in the 
BUILDING.md file, which will be updated by this commit.

Running tests with parallelDunit. If you use -PparallelDunit to run tests in 
Docker, either in a script or on the command line, you will need to change a 
few command line options:

  *   -PdunitParallelForks= is no longer used. It has been replaced by 
--max-workers and testMaxParallelForks.
  *   --max-workers= specifies the maximum number of worker processes for 
Gradle to run in parallel. Set that to whatever value you used for 
dunitParallelForks.
  *   -PtestMaxParallelForks= specifies the maximum number of tests for each 
Dockerized test task to run in parallel. Set that to the value you used for 
dunitParallelForks.

Dale

Re: [DISCUSS] Pull Request (PR) check list

[Jacob Barrett]

I honestly ignore the checklist.

> On Apr 8, 2021, at 2:24 PM, Anilkumar Gingade  wrote:
> 
> It is been some time we have been using a standard check-list for PRs. It 
> may be time to look back and see if any of them were obsolete; and add new 
> items based on the PR review experience.
> 
> Current PR check list items:
> 
>  1.  Is there a JIRA ticket associated with this PR? Is it referenced in the 
> commit message?
>  2.  Has your PR been rebased against the latest commit within the target 
> branch (typically develop)?
>  3.  Is your initial contribution a single, squashed commit?
>  4.  Does gradlew build run cleanly?
>  5.  Have you written or updated unit tests to verify your changes?
>  6.  If adding new dependencies to the code, are these dependencies licensed 
> in a way that is compatible for inclusion under ASF 2.0?
> Based on how the PRs are created and with review requirement/process in 
> place, the check-list from #1 - #5 seems to be obsolete.
> 
>  *   Ticket numbers are used/referred in PR
>  *   The merging option shows if there is any conflict with base repo
>  *   Unit tests are run on the PR and reviewers are expected to look for 
> new/existing tests to be added/modified.
> 
> Adding some of the criteria we often miss out during the code changes could 
> be more valuable to add into the checklist, e.g.:
> 
>  *   Any serialization changes done; requiring 
> backward-compatibility/rolling-upgrade testing
>  *   Is there any performance implication with these changes
>  *   Was there any RFC for this PR and needs to be updated (link to the RFC)
> 
> 
> Please share your thoughts/comments.
> 
> Thanks,
> -Anil
> 

[DISCUSS] Pull Request (PR) check list

[Anilkumar Gingade]

It is been some time we have been using a standard check-list for PRs. It may 
be time to look back and see if any of them were obsolete; and add new items 
based on the PR review experience.

Current PR check list items:

  1.  Is there a JIRA ticket associated with this PR? Is it referenced in the 
commit message?
  2.  Has your PR been rebased against the latest commit within the target 
branch (typically develop)?
  3.  Is your initial contribution a single, squashed commit?
  4.  Does gradlew build run cleanly?
  5.  Have you written or updated unit tests to verify your changes?
  6.  If adding new dependencies to the code, are these dependencies licensed 
in a way that is compatible for inclusion under ASF 2.0?
Based on how the PRs are created and with review requirement/process in place, 
the check-list from #1 - #5 seems to be obsolete.

  *   Ticket numbers are used/referred in PR
  *   The merging option shows if there is any conflict with base repo
  *   Unit tests are run on the PR and reviewers are expected to look for 
new/existing tests to be added/modified.

Adding some of the criteria we often miss out during the code changes could be 
more valuable to add into the checklist, e.g.:

  *   Any serialization changes done; requiring 
backward-compatibility/rolling-upgrade testing
  *   Is there any performance implication with these changes
  *   Was there any RFC for this PR and needs to be updated (link to the RFC)


Please share your thoughts/comments.

Thanks,
-Anil

Re: [DISCUSS and NOMINATE] Time for a new Geode PMC Chair

[Anthony Baker]

Karen, thanks for taking on the role of PMC Chair for Geode over the last few 
years!

The process for changing the Chair is outlined at [1].  The nominations and 
voting usually seem to occur on the PMC email list.  I’ll start a thread on 
private@.

Thanks,
Anthony

[1] https://www.apache.org/dev/pmc.html



> On Apr 7, 2021, at 1:58 PM, Karen Miller  wrote:
> 
> I've been the Geode PMC chair since December 2018. I'd like to step
> down from this position as soon as we nominate and then vote on a new
> PMC chair. (See https://www.apache.org/dev/pmc.html#newchair)
> 
> Please use this email thread to discuss and nominate. I believe the
> only requirement for the PMC chair is that the person already be a
> Geode PMC member. You are welcome to self-nominate, or to nominate
> another person. After nominations have been made, there will be a
> separate thread to allow current PMC members to vote on who will
> become the new PMC chair.
> 
> Thanks.
> Karen Miller
> I work for VMware.
> This email is written in my capacity as Chair of the Apache Geode PMC.