@jeremiah, perhaps open a JIRA and tag it as Airflow 2.0, so we don't lose track?
On Thu, Jun 2, 2016 at 1:46 PM, Jeremiah Lowin <[email protected]> wrote: > 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 > > > > >> > > > > > > > > > > > > > > > > > > > >
