I think the observation is that if it were consumed as a third party dependency, the separation of concerns would be more crystal clear than with the code living in a quasi-monorepo. Right now it's neither documented nor clear that it can operate in isolation from Aurora.
On Wed, Jun 24, 2015 at 3:50 PM, Bill Farner <[email protected]> wrote: > I may not be thinking hard enough about it - but wouldn't consuming it as a > third-party dependency add to the problems? > > -=Bill > > On Wed, Jun 24, 2015 at 3:44 PM, Maxim Khutornenko <[email protected]> > wrote: > > > I generally agree on the cognitive overhead point as it's not easy to > > maintain mental picture of all dependencies especially for someone > > without much domain knowledge. > > > > That said, I recognize the value of Thermos that was conceived as a > > standalone system not necessarily constrained by the Aurora. Would it > > make sense to consider forking Thermos out as an independent project > > and consume it as an external versioned dependency? Is Thermos > > independence worth the increased development overhead? > > > > On Wed, Jun 24, 2015 at 3:35 PM, Kevin Sweeney <[email protected]> > wrote: > > > I think the abstraction has outlived its value, proven by the fact that > > > there are parts of thermos that are completely untested and broken (see > > gc > > > subcommand) that maintaining them isn't worth the overhead. > > > > > > I think my comment here sums up my feelings on this issue and points > out > > > some of the shortcomings of maintaining the abstraction barriers as > they > > > exist today > > > > > > https://issues.apache.org/jira/browse/AURORA-1338?focusedCommentId=14561777&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14561777 > > > > > > On Wed, Jun 24, 2015 at 3:13 PM, Bill Farner <[email protected]> > wrote: > > > > > >> Since there's been a recent uptick in development on the executor, > > there's > > >> a long overdue discussion that i would like to raise. > > >> > > >> Does it make sense to continue maintaining the abstraction between > > >> 'thermos' and the 'default Aurora executor'? I see this as cognitive > > >> overhead in the code, and it adds non-trivial complexity that is not > > used > > >> in practice in Aurora. > > >> > > >> > > >> -=Bill > > >> > > >
