I'd love to do it. Actually this + refactoring the core.py tests would be amazing.
But the amount of havok to fix stuff afterwards, including temporary compatibility adjustments would require maybe a temporary lock of quiet time on the models. It is hard to catch all of the added changes in the rebases. Should we merge the remaining few Scheduler PRs first and then do the refactor? Best, Arthur On Thu, Jun 2, 2016 at 6:03 AM, Jeremiah Lowin <[email protected]> wrote: > Models.py is becoming monolithic. We've discussed refactoring it many > times. No way around this: refactoring it will suck. It will break PRs and > require rebases. It will make it impossible to see diffs. > > On the other hand it will make future changes much more manageable. It will > implicitly address concerns about PRs that touch "core" areas because we'll > be able to see if "dags.py" is altered, as opposed to "xcom.py". It will > make the codebase more digestible and clear. > > I'm not exactly lining up to champion this but it will only get harder and > harder to do so I want to raise the issue to the list... > > J >
