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