Gotcha. From my perspective, the overhead is much greater than avoiding commits that span the two folders. We'll own the complexity no matter where it lives. My point is that there's code and complexity in thermos that we could discard if we don't treat thermos like an independent entity with the features it has today.
-=Bill On Wed, Jun 24, 2015 at 3:53 PM, Brian Wickman <[email protected]> wrote: > 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 > > > >> > > > > > >
