Mehul Kar

> Then shouldn't the priority be ironing out the kinks in fastboot? We're using FB successfully for years now. Sure there are "kinks", but they haven't blocked anything from getting...

Generally in favor of some way to "passthrough" args, but in order to determine what `...@arguments` does, we need to first define `@arguments` and its relationship to `this.args` in glimmer...

> Second, I'm strongly against on* methods. It is application.setup() rather than application.onBoot(). The first not only tells a better story, the method is an active part not a reactive...

> Here are a few: preBoot(), postBoot() rsp beforeBoot(), afterBoot() I'm open to this, but we'd have to first define "boot". If we simply called `postBoot` at the end of...

> but I do not want to land a change to how initializers work only to subsequently deprecate them 1. This wouldn't change how they work! It would just mean...

@rwjblue any additional thoughts about this one?

> Will any of the addon provided initializer not run? In that case how would an addon author communicate with the app consumer? `import { loadInitializers, loadInstanceInitializers } from 'ember-load-initializers';`...

I still believe this is a good idea and the right abstraction for an ember application. I am no longer working primarily in Ember though, so I’m not sure how...

This RFC should also probably provide some text about how to register/inject services in component rendering tests.

The main problem being solved here is traceability. “Why does inject with this string mean that this Singleton is available?” An alternative solution (and less disruptive I think), would be...