[GitHub] [airflow] kaxil commented on issue #12983: Add support selective docs/tests (provider-related) building in CI build-docs step

[GitBox <gi...@apache.org>]

kaxil commented on issue #12983:
URL: https://github.com/apache/airflow/issues/12983#issuecomment-762418986


   >This is what I want to avoid. I would like to focus more on contributing to the project or to project documentation, rather than contributing to the contributing tools, unless absolutely necessary. A very small group of people wants to focus on contributing to the tools for contribution.
   
   Strongly agree with this statement from @mik-laj . 
   
   >The only way to get better is to continuously improve your tools, especially when you can improve lives of many people by making improvements. I think this is extremely important.
   
   Agree with that in principle, but the most important part of the contributing tool is "stability". If optimisation comes at the cost of stability and making it less easy to comprehend (our CI system is already getting difficult to grasp at least all of it). 
   
   >And any time we found we missed one and it caused faillure we can find it and fix it if we find it caused problem (and incrementally get better at catching such cases). We will not get it perfect the first time, but it's fine. We will catch it an fix it, at the same time vast majority of the build will benefit from that.
   
   That is causing a significant issues with UX because Master starts failing and we need to tell everyone to rebase to Master. I can understand it when it is absolutely needed or a big optimisation but for the current docs optimisation, while the (3) or (4) we mentioned in the comment would be good to have but not if it comes with a cost.
   
   
   >This is a very subjective word. For some, it is important that the tools are stable, reliable and as simple as possible. For others, it is more important that they are fast, efficient, feature-full, but this can create difficulties with stability and reliability and add more complexity. I am in favor of introducing these optimizations if we are confident in its stability and reliability, and it is also easy to maintain.
   
   Agree with this 100% too -- I would strongly prefer stability than speed. Like Kamil said -- only if it necessary or does not compromise stability otherwise that time can be used to improve the Product itself. The CI system / script should not become a product of it's own. It is there to compliment the product and make it more stable -- which with breeze I think we already have.


----------------------------------------------------------------
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.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org