A final observation, since this may include breaking changes, should we target these large refactors for 2.0 rather than 1.8?
I agree that these are important changes, but maybe getting our feet wet with an apache release or two to settle on a release process (+ testing infrastructure less dependent on Airbnb) before breaking too much stuff might not be a bad idea. Best, Arthur On Thu, Jun 2, 2016 at 9:50 AM, Arthur Wiedmer <[email protected]> wrote: > 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 >> > >
