potiuk commented on PR #30727: URL: https://github.com/apache/airflow/pull/30727#issuecomment-1537334851
> Yes, I agree that just dropping the change and re-implementing it is the easier way than maintaining the branch long term. **But** to me the real issue is that this will block my progress on multiple PRs (I have one open for Celery that I assume will also now be rejected) and thus AIP-51 (which itself has a CLI PR open waiting for these changes), which is really a shame. I'm not sure blocking all that progress on an AIP is worth it to just avoid a possible non-trivial cherry-pick (which I'm happy to help with if it does arise). I think that is the missing piece of information that changes my view (or maybe I missed it). I propsed delying that one because I thought the only reson for having this chang is load time optimisation (which would not be used anyhow before 2.7 is releasd). It fhere are other reasons and follow-up PR that are waitng for that one, this is quite entirely a different story. In such case I agree, that merging that one should not wait for too long and in this case (especially if you are going to help with cherry-picking) it's perfectly fine to merge it. The question is - is it really the case? Are those other PR really depending on that one? Or can they be done without the optimisation and the optimisation can be applied later? * If it is the former - It would be stupid to wait with changes that are blocking further changes. * If it is the latter - I would proceed with the other change now and defer applying this optimisation till before the cut-off I have completely no problem if it's the former with merging it now. -- 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]
