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 <vro...@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 <mich.talebza...@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 <vro...@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 <her...@databricks.com.INVALID> wrote: What do you need to have reviewed? On Mon, Dec 30, 2024 at 3:48 PM Rozov, Vlad <vro...@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
