<br><br><div class="gmail_quote">On Sat, Nov 17, 2012 at 9:08 AM, Jiang, Yunhong <span dir="ltr"><<a href="mailto:yunhong.jiang@intel.com" target="_blank">yunhong.jiang@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">> * Transforming roadmap items into blueprints  (nijaba, 15:22:00)<br>
>   * ACTION: nijaba to transform bp-less features into bp  (nijaba,<br>
>     15:23:27)<br>
>   * LINK: <a href="http://wiki.openstack.org/EfficientMetering/RoadMap" target="_blank">http://wiki.openstack.org/EfficientMetering/RoadMap</a>  (eglynn,<br>
>     15:24:38)<br>
>   * AGREED: ceilometer team to use bp to track status of features<br>
>     (nijaba, 15:27:01)<br>
><br>
<br>
</div>This is different with <a href="http://wiki.openstack.org/EfficientMetering/RoadMap" target="_blank">http://wiki.openstack.org/EfficientMetering/RoadMap</a>, which state "each item should point to a wishlist bug in Launchpad." So now will it has only blueprint?<br>
</blockquote><div><br></div><div>Yes, ttx uses the blueprints to track release progress so we need to switch to blueprints instead of wishlist items.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Just realized that developer can assign bugs to themselves freely, but not for blueprint, which will make status update more easily (owned by assignee themselves).<br></blockquote><div><br></div><div>The ceilometer-drivers group can probably assign blueprints (if not, we'll figure out who has that permission). So if you want to volunteer to take one on, send email to the mailing list or bring it up during a meeting and we'll make sure the owner is set correctly. Having that extra coordination step will help us prevent duplicating effort anyway, so maybe forcing the communication isn't a bad thing?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Also, I think some items can be updated, but I'm not sure if only Nicolas can edit them. For example, since option 5 is ok for nova team, "support for non libvirt Hypervisors" does not matter now , and seems we can't get "remove all nova imports" anymore, since we at least need one library import :)<br>
</blockquote><div><br></div><div>We still want the non-libvirt hypervisors feature, but the implementation details have changed. I don't think that means we want to close the blueprint. The import item may just need to change to "remove unnecessary nova imports," since we still want to get rid of the use of nova flags if possible.</div>
<div><br></div><div>Doug</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks<br>
--jyh<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br>