potiuk commented on issue #5461: [AIRFLOW-4835] Refactor render_template URL: https://github.com/apache/airflow/pull/5461#issuecomment-511666687 Side comment @nuclearpinguin @BasPH -> I think we should adapt our approach for pylint changes a bit after first experiences with it. This (and other) cases shows that we rarely naturally fix all the pylint problems per-file. While it worked fine for GCP operators/tests, I think the approach proposed by @mik-laj works a bit nicer: https://github.com/apache/airflow/pull/5587#issuecomment-511205537, however maybe we can modify it slightly. I like the idea that you won't fix it file-by-file but warning-by-warning. It sounds much more natural. But I do not like the idea that this means that files will not disappear from the todo list as quickly as we would like them to, and will not prevent people from adding new pylint errors in the meantime to files that are already pretty much cleared. @mik-laj already has a script that produces updated pylint_todo.txt so we can regularly re-run and update it (it does not have to be always when we fix some errors - it can be independent and regular). However I think what might make sense is to combine this approach - maybe we could extend the script that will run pylint on the whole codebase and produce updated pylint_todo.txt list + list of candidates that can be cleaned really quickly (basically with a few pylint problems left). This way our natural process of fixing pylint problems would look as follows: 1) Fix particular warning across the board (rinse-repeat for different warnings types) - this can be done independently by different people 2) Regularly (weekly ??) regenerate pylint-todo.txt + fix those files with just a few errors left 3) Repeat. What do you think @BasPH @mik-laj @nuclearpinguin ? @mik-laj - I know you have some tools/scripts that you use to automate some of that work (like creating JIRA issues etc). Maybe you could create a PR with those tools that others (us?) could use as well and we could setup a small 'process' for that. We are down to 4000 errors or so from 5000 but I feel that if we establish this kind of small process, we can invite others to help with the effort and get it done much more quickly. Especially we could encourage new contributors of Airflow to help with that if we give them easy to use process/tools to do it.
---------------------------------------------------------------- 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: [email protected] With regards, Apache Git Services
