# Misc housekeeping and notes -- Release 0.8 timetable, freeze dates, tickets by milestone, what's on deck for 0.9 **URL:** \ **Category:** Ansible Project\ **Created:** [October 11, 2012, 1:09am UTC](https://forum.ansible.com/t/misc-housekeeping-and-notes-release-0-8-timetable-freeze-dates-tickets-by-milestone-whats-on-deck-for-0-9/11968 "2012-10-11T01:09:37Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [October 11, 2012, 1:09am UTC](https://forum.ansible.com/t/misc-housekeeping-and-notes-release-0-8-timetable-freeze-dates-tickets-by-milestone-whats-on-deck-for-0-9/11968/1 "2012-10-11T01:09:37Z")
The bug queue for 0.8 is getting to be pretty reasonable. I am planning on squashing tickets through the weekend so we can deliver 0.8 shortly. Please review any open bugs and see if you can help squash any of them: [https://github.com/ansible/ansible/issues?milestone=1&state=open](https://github.com/ansible/ansible/issues?milestone=1&state=open) Dates for 0.8 release are as follows: Feature freeze: this Friday 12PM midnight EST ... no new pull requests for features (bugs are ok) Testing and any bugfixes: next Monday through Thursday Release: following Friday night You will notice I have moved some bugs and feature ideas to 0.9 already. [https://github.com/ansible/ansible/issues?milestone=2&page=1&state=open](https://github.com/ansible/ansible/issues?milestone=2&page=1&state=open) A lot of these are RFEs or borderline RFEs and I'll be dependent on everyone here to help work on particular issues for 0.9 once 0.9 starts. This is already a pretty large list. RFEs without volunteers may not all get implemented. Major 0.9 themes for me in 0.9 will include resurecting ansible-commander (in part, anyway), the new 'when' keyword (providing an easier only\_if), making a pluggable system for looking up variables in external systems which jp\_mens has already prototyped, and reducing the number of runner operations for performance operations (like doing template+file and copy+file all in one module call, and exploring modules that do directory cleanup versus a seperate tempdir call). I suspect about a 30-40% reduction in remote operations is possible in 0.9. So yeah... --Michael ---
**Author:** ![Tim\_Bielawa](https://avatars.discourse-cdn.com/v4/letter/t/ed8c4c/32.png) [@Tim\_Bielawa](https://forum.ansible.com/u/Tim_Bielawa)\ **Post date:** [October 11, 2012, 1:27am UTC](https://forum.ansible.com/t/misc-housekeeping-and-notes-release-0-8-timetable-freeze-dates-tickets-by-milestone-whats-on-deck-for-0-9/11968/2 "2012-10-11T01:27:05Z")
Sounds nice. But there's one thing, and I mean this in a constructive way: Prove it. Metrics. Do you have any data collected showing the current number of remote operations? A good sample set to collect that from might be the examples directory. The graphs need more rounded corners and drop shadows. And graphs. ---
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [October 11, 2012, 1:46am UTC](https://forum.ansible.com/t/misc-housekeeping-and-notes-release-0-8-timetable-freeze-dates-tickets-by-milestone-whats-on-deck-for-0-9/11968/3 "2012-10-11T01:46:11Z")
You can do it now with "-v -v -v". I've bounced strategies around with skvidal and mgwilliams a fair amount several months ago so this is mostly just a culmination of that. It works roughly like this (as you can see from -v -v -v) today: Mkdir temp dir md5sum remote file to decide if we need to copy Transfer copy module file into tempdir Run module file transfer actual file Transfer flie module file into tempdir (daisy chain second module) Run module file Delete tempdir That's 8 operations. It used to be a little worse before as before new style modules the args file was a seperate file, and if you are executing a non-python or old-style module that is still true. Of course 8 is a bit many here because it's file or template... and if you are using ControlPersist or whatever it's not terrible, and there's still the paramiko caching idea thing. But anyway, reducing runner ops is actually the lowest hanging proverbial fruit. This could easily be Mkdir temp dir md5sum remote file to decide if we need to copy transfer copy module that knows how to do all file can do because it's in module common transfer actual file run module file and the module file was told where the tempdir was so it can self delete That's 5 operations, saving 3. That's a pretty big cut. We can also eliminate daisy chaining in other places, like the get\_url module, and if we are lucky, eliminate the daisy\_chaining part of the code base altogether (unless we decide to keep it around for non-Python modules, but I'm drawn on this). If you are pushing a module that does not require any auxilliary files and does not daisy chain (such as, say, service), you can break it down to: push module to temp /file/ location transfer module run module and have it self delete Which is 3 operations (down from 5 or 6 or so) When we do this, we'll definitely be collecting benchmarks and I'll probably even add a mode that keeps benchmark data inside hostvars so we can do before and afters, and not just wallclock time... --Michael