That all makes sense to me. I knew I wouldn't win any popularity contests by bringing this up but I think we should keep it in mind in case it becomes more feasible for any reason.
On Thu, Jun 2, 2016 at 3:21 PM Chris Riccomini <[email protected]> wrote: > I agree with what Arthur/Maxime said. > > On Thu, Jun 2, 2016 at 11:32 AM, Maxime Beauchemin < > [email protected]> wrote: > > > I think it's possible to do it without breaking the API by frontloading > > things in `models/__init__.py`, but there are way so many things in > flight > > at the moment that to me this effort qualifies as low-ish value and high > > complexity. > > > > Cycles spent refactoring the tests would be a much better investment from > > my perspective. > > > > Max > > > > On Thu, Jun 2, 2016 at 9:54 AM, Arthur Wiedmer <[email protected]> > wrote: > > > > > 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 > > > >> > > > > > > > > > > > > > >
