can agree with that, just dont want to see us forget about it and have
stale code sitting around. moved to the 0.10 deprecations epic
-Jake
On Tue, Sep 15, 2015 at 8:26 PM, Bill Farner wrote:
> TODO cleanup seems to be an ongoing process, and much like documentation -
> i think it's tricky to p
TODO cleanup seems to be an ongoing process, and much like documentation -
i think it's tricky to put on a roadmap.
On Tue, Sep 15, 2015 at 1:19 PM, Jake Farrell wrote:
> we should probably spend some time before .10 going through and cleaning up
> deprecation todo's left in the code also. I've
we should probably spend some time before .10 going through and cleaning up
deprecation todo's left in the code also. I've added this to the Aurora
Roadmap Google doc
-Jake
On Thu, Sep 10, 2015 at 2:09 PM, Bill Farner wrote:
> I agree, documentation overhauls are best decoupled from releases.
>
Isn't this data supposed to be any blob that transparently passes in to the
executor through mesos data blob. Why would we want to impose any sort of
format? It could be a binary blob. Executor writers should be able to move
between different schedulers/frameworks without any rework ideally. Thi
I'm a proponent of firming up our executor <-> scheduler contract. Since we
are going to get multiple executor support soon I think it would be nice if
we said that ExecutorConfig.data was JSON.
On Tue, Sep 15, 2015 at 10:47 AM, Maxim Khutornenko
wrote:
> | I hope this doesn't mean we would be r
| I hope this doesn't mean we would be returning a textual
representation of a diff
If we can make an assumption that executor data is always JSON, we can
deliver a much more specific answer by applying JSON diff tools.
Something like:
- "environment": "prod"
+ "environment": "test"
Otherwise, w
