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 > >> >
