Re: PR review

["Rozov, Vlad" <vr...@amazon.com.INVALID>]

May I please get review on the following outstanding PRs:

https://github.com/apache/spark/pull/49276 (open on 12/23/2024)
https://github.com/apache/spark/pull/49870

Thank you,

Vlad

On Feb 25, 2025, at 5:31 PM, Rozov, Vlad <vr...@amazon.com.INVALID> wrote:

Thanks, looking for committers to review/discuss my pending PRs: https://github.com/apache/spark/pulls/vrozov

Thank you,

Vlad

On Dec 31, 2024, at 6:47 AM, Mich Talebzadeh <mi...@gmail.com> wrote:


This is my experience

 1) Initial Discussion in this email list

Subject Line: Use a clear subject line that indicates the nature of the improvement. For example: [DISCUSS] Improve warning logging in CacheManager.

Followed by

  *   Briefly describe the problem you're addressing.
  *   Clearly outline your proposed solution.
  *   Explain the benefits of your improvement.
  *   If you have a preliminary patch or prototype, you can include it or link to it (e.g,  https://github.com/apache/spark/pull/49276).
  *   Explicitly ask for comments and feedback.

2. Discussion and Refinement:

Mailing List Thread: The discussion will take place on the Spark developer mailing list (here)
Time for Discussion: Allow sufficient time for discussion (usually a few days to a week or more, depending on the complexity of the change).
Refinement: Based on the feedback you receive, you will likely need to refine your proposal

3. Pull Request:

  *   Create a PR: Once the discussion has converged and you have a solid implementation, create a pull request against the Apache Spark repository on GitHub.
  *   Link to the Discussion: In the PR description, include a link to the original email thread on the mailing list. This provides context for reviewers.

4. Review and More Discussion (on the PR):

  *   Code Review: Committers and other contributors will review your code in the PR.
  *   Further Discussion: Further discussion and feedback will often take place directly on the PR.
  *   Revisions: You will likely need to revise your code based on the review comments.

5. Voting:

  *   When to Vote: Once the review is complete and the code is considered ready, a vote can be called. This is usually done by a committer.
  *   Vote Thread: The vote takes place on the same dev list
  *   Vote Subject: Use a subject line like [VOTE] Improve warning logging in CacheManager. The [VOTE] tag is essential.
  *   Vote Options: The standard vote options are:
     *   +1: Approve/Accept
     *   +0: Neutral/No strong opinion
     *   -1: Disapprove/Reject
  *   Binding vs. Non-Binding Votes:
     *   Committer Votes: Committer votes are binding. This means that if a majority of committers vote +1, the change will be accepted, regardless of the non-committer votes.
     *   Non-Committer Votes: Non-committer votes are non-binding but are still very important. They provide valuable feedback and can influence committer votes.

6. Vote Counting and Announcement:

  *   votes typically last for 3 days to allow sufficient time for everyone to participate.
  *   vote Counting: After the voting period, the person calling the vote (usually a committer) counts the votes.
  *   Vote Result Announcement: The result is announced on the mailing list with a summary of the votes (e.g., +1: 3, +0: 1, -1: 0).

Key Clarifications:

  *   Pinging Committers: You can ping committers directly (on the PR or in the email thread) to get their attention, especially if the discussion has stalled or you need specific expertise.
  *   What matters: Even though committer votes are binding, committers will generally try to reach a consensus with the community before making a decision.
  *   Have a look at the mailing list, Reviewing past discussions and votes on the dev list will be very helpful and informative.

HTH

Architect | Data Science | Financial Crime | GDPR & Compliance Specialist
PhD Imperial College London London, United Kingdom


 [https://ci3.googleusercontent.com/mail-sig/AIorK4zholKucR2Q9yMrKbHNn-o1TuS4mYXyi2KO6Xmx6ikHPySa9MLaLZ8t2hrA6AUcxSxDgHIwmKE]   view my Linkedin profile<https://www.linkedin.com/in/mich-talebzadeh-ph-d-5205b2/>

 https://en.everybodywiki.com/Mich_Talebzadeh



Disclaimer: The information provided is correct to the best of my knowledge but of course cannot be guaranteed . It is essential to note that, as with any advice, quote "one test result is worth one-thousand expert opinions (Werner <https://en.wikipedia.org/wiki/Wernher_von_Braun> Von Braun<https://en.wikipedia.org/wiki/Wernher_von_Braun>)".


On Mon, 30 Dec 2024 at 21:47, Rozov, Vlad <vr...@amazon.com.invalid> wrote:
I have an open PR https://github.com/apache/spark/pull/49276, though my question is more generic. After PR is open, should a contributor wait for it to be reviewed or is it necessary to ping committers? According to https://spark.apache.org/contributing.html the advice is to ping committers. On the other side I checked few open PRs and I don’t see such requests.

Thank you,

Vlad


On Dec 30, 2024, at 1:09 PM, Herman van Hovell <he...@databricks.com.INVALID> wrote:

What do you need to have reviewed?

On Mon, Dec 30, 2024 at 3:48 PM Rozov, Vlad <vr...@amazon.com.invalid> wrote:
Hi,

How can I request PR review? Sorry if this was already discussed on the list or is available in the archive or spark.apache.org<http://spark.apache.org/>.

Thank you,

Vlad