aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maxim Khutornenko <>
Subject Re: Should we maintain the thermos abstraction?
Date Wed, 24 Jun 2015 22:44:58 GMT
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 <> 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
> On Wed, Jun 24, 2015 at 3:13 PM, Bill Farner <> 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

View raw message