potiuk commented on issue #45691: URL: https://github.com/apache/airflow/issues/45691#issuecomment-2599659352
> "eh, I don't want to have to look at another argument in the config" Yes. that's a very good reason in fact. Adding more confusion and options is not desireable "product" property. Sometimes even at the expense not handling all cases. You can have a product with million configurable parameters that is useless and far too generic. So "I do not want to have yet another knob to turn" is quite a good reason for not accepting it - from product point of view, even if individual cases are not happy. Generally it's impossible to make everyone happy, some people will still be somewhat unhappy. This looks like an important change in behaviour that also might impact some of the other discussions we have about Airlfow 3 - namely a lot of discussions about https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-83+amendment+to+support+classic+Airflow+authoring+style and resulting in https://cwiki.apache.org/confluence/display/AIRFLOW/Option+2+clarification+doc+WIP . While not 100% related, this PR and the backfill change mentioned by Elad are very much related to the catchup behaviour and show how you should approach such discussions. My suggestion is @seth-olsen if you feel very strongly about this one, start a discussion on devlist and put forth your arguments. Analyse all the past dicussions that @eladkal so helpfully provided, read them in detail, anylyse why thigns were rejected - try to understand other's arguments (even if you do not agree with them, trying to understand what others are saying is a good idea), and come up with a concrete proposal how you think your case should be addressed and justify it. Eventually everything we do is consensus driven (i.e. we want to get to consensus where generally we agree to a direction) but if we cannot reach consensus, the last resort is voting https://www.apache.org/foundation/voting.html Note that - similarly to what Daniel did, when presenting your proposal you shoudl consider all the cases and combinations in your proposal, what it means what consequences it has when introduced, what it means for backwards compatibility etc.. Just thorough thinking followed by discussion, reaching consensus and if not possible, defining the outcome and calling for a vote. Your case is way simpler than what Daniel discussed, but the mechanism is very similar. So I propose you start a `[DISCUSS]` thread on our devlist, where you explain rationale and refer to the past dicussions - but make sure it covers all cases and earlier arguments , let it run for a while and have people discuss it, drive it to consensus if possible and then call for a vote when you think general direction is set. -- 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: commits-unsubscr...@airflow.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
