potiuk commented on PR #22253:
URL: https://github.com/apache/airflow/pull/22253#issuecomment-1691529880

   > > @hamedhsn Could you check the failed tests?
   > 
   > sorry, there is no point in updating this code anymore as there is no 
intention of reviewing/merging this PR.
   
   Why do you think so ? I don't think anyone ever said that - you are making a 
bit unfounded assumptions. I think you should try to exercise a bit of empathy 
here. I recommend this talk https://www.youtube.com/watch?v=G6VjYvKr2wQ which 
was quite a bit inspired by the @vsoch's talk (she commented here so that's why 
I am mentioning)  from years back  - it was also a huge PR and it took 10 
months https://airflowsummit.org/sessions/adding-executor-airflow/ and we all 
learned from it - this pr is still not THAT long considering the size of it.  I 
think a little empathy and assuming good intentions goes a long way.
   
   Look at my talk and the numbers - in fact - on you to be persistent and 
remind people to review your PR. We have 100s of PR to look a day sometime. So 
if you (who have only one PR to tend here) will not remind gently but 
persistently, it might be that people miss it and never come back. The tooling 
is not perfect. We have ~ 160 PRs opened at any time. Nobody has a time to  
look at all PRs and make sure they have been properly looked at. On the other 
hand you can rebase, fix tests and periodicaly remind that it's "rady for 
review". You have one PR. As opposed to people looking and many of those - it's 
feasible for you to pay more attention and remind regularly. Just try to put 
yourself in the shoes of maintianers.
   
   While I understand you might be frustrated by long waiting, and - in the 
name of maintainers who had not communicated it - apologise - I think you 
should understand the context. This is an open source project where maintainers 
volunteer their time and energy to review and help others to contribure. 
   
   The fact that some of the busy maintainers did not have time to review it 
even for a long time does not mean they have no intention. Everyone here is a 
human and have their, live, priorities and finite amount of energy to spend. 
People here volunteer mostly to help others to contribute. They might have 
other priorities, they could have been on hoildays, or simply had situations in 
their lives that did not allow them to spend a lot of time - for examaple they 
had to choose whether to tend to their family or look at some of the PRs.
   
   I think the fact that someone actually ask you to review a PR is a sign that 
there is an interest. So I think little persistence and empathy towards the 
fact that there actual humans on the other side goes a long way . Your PR is 
huge 1200 new lines of code - that's why it can take a long time for someone to 
reserve enough of their time and capacity to be able to review it. When you 
look at other PRs that gets merged quicker, they are 10-100 lines of code. So 
maybe a good idea to split your PR into smaller pieces and introduce them 
gradually? It's your decision of course and if you still want to contribute it, 
I'd encourage you to explore this path as welll.
   
   In the meantime, like with every other PR here, things can get outdated, 
other PRs get merged so we ask authors to review and rebase their PRs 
periodically even if they are not reviewed.  Generally speaking when there is 
PR with failing tests (especialy big ones) - we do not even look at it until 
the tests are fixed, especially when they are big, because the code might 
change significantly in order to fix tests. We treat the tests as "automated 
reviewer" that should guide the user in solving problems that can be caught 
automatically and save the time for reviewers. You have to remember that you 
have one PR you are looking at and we have sometimes 100 PRs a day to look at 
and only part of our time is put aside to do those reviews. So by making the PR 
"green" you give the reviewers a signal that the "first line" of checks have 
already passed.
   
   By doing it you also have a much better chance that you wil be able to fix 
any conflicts qucker and less painfully, "rebase early, rebase often" is a 
mantra I keep on repeating everyone.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to