So, to address some questions.

(A) Definitely file tickets on bugs. If there are things we don't know about we can't fix them :)

(B) Role dependencies I think are what you may mean. They are on deck for inclusion in 1.3 which is out this month.

(C) I would agree that core modules aren't subclassable by design though this is largely an artifact of how we are engineered to not have any dependencies for getting things going on remote nodes (zero bootstrapping). For the most part it works well and I'm fine with moving get_url into module common.

(D) Yay variable scope thread! No doubt, I do have opinions and we want to fight to keep things minimal. There was a recent proposal to inject role variables into the local namespace that fixes most of this, this is also something we are going to do in 1.3. I think that will eliminate most of the "prefix" ideas when you have variables defined in multiple places. I still think group_vars/ is a great place for defaults :)

Hi Michael, congratulation first and thanks for your prompt reply. It is amazing how you can be so attentive to the community.

For (c), I think you misunderstood my point, I am not saying to make modules re-usable by exposing the function/method directly, instead, I against them as it will make the module common very bulky. I am saying to have a way to launch a sub-task within a custom module (task) in order to reuse the existing goodness, e.g. I want to put a file to S3 in my module, why I need to use low level api such as boto when I can re-use the existing s3 task - just one line!

For (d), I am reasoning using common sense only, e.g. 10gen distribute the mongodb playbook, declared the default port of 27017 in the playbook, and I am using group_vars to manage mongodb replica sets at different datacenters, either I am satisfying with the default in the playbook, or otherwise, I can simply override them in my group_vars. I don't want to modify the playbook and 10gen can't access my group_vars, to me or people in the mailing list, it make a lot of sense to have the defaults in the playbook. To keep things minimal, honestly, you don't need to introduce new stuff for this, just revert it by changing the priority in the next major release and give people enough warnings and people will understand.

While I see your point on (C), there are characteristics of ansible that have led to that point, such as zero-boostrapping and keeping things very efficient. So yes, I agree that's true, but it hasn't been much of a problem so far.

(D) We're pretty big about backwards compat, so I'm definitely not going to be reverting any priorities. I think a lot of people DO like the way things are set up now. I'm open to including a 'defaults/' type directory in roles though and that's something we are exploring for those that want to ship defaults and don't want to edit their group_vars for whatever reason.

aye... opinionated he is :)