<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 13, 2013 at 4:20 PM, Eric Windisch <span dir="ltr"><<a href="mailto:eric@cloudscaling.com" target="_blank">eric@cloudscaling.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">>> Each project should directly use the standard uuid module or implement its<br>
>> own helper function to generate uuids if this patch gets in.<br>
>><br>
>> Any thoughts on this change? Thanks.<br>
><br>
><br>
> Unfortunately it looks like that change went through before I caught up on<br>
> email. Shouldn't we have removed its use in the downstream projects (at<br>
> least integrated projects) before removing it from Oslo?<br>
<br>
</div>I don't think it is a problem to remove the code in oslo first, as<br>
long as no other oslo-incubator code uses it. Projects don't have to<br>
sync the code and could always revert should that they do.<br></blockquote><div><br></div><div>Well, I wanted to avoid having projects decide that merging Oslo code was a hassle or risky, because that breaks the promise of the project. We talked at the summit about providing patches to consuming projects when we break Oslo APIs, and I think that's a reasonable approach. When we do break an API, we want to ensure that we at least have a plan for how consumers could be updated. WIP patches for the consumers show that we've thought through the changes sufficiently to at least continue to cover our existing use cases.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
However, like Mark, I'm inclined to consider the value of<br>
is_uuid_like. While undoubtedly useful, is one method sufficient to<br>
warrant creating a new top-level module. Waiting for it to hit the<br>
standard library will take quite a long time...<br>
<br>
There are other components of oslo that are terse and questionable as<br>
standalone libraries. For these, it might make sense to aggressively<br>
consider rolling some modules together?<br>
<br>
One clear example would be log.py and log_handler.py, another would be<br>
periodic_task.py and loopingcall.py<br></blockquote><div><br></div><div>I like having the modules separate, and don't think each top-level module implies a standalone library after graduation. For example, there are some other modules related to string formatting that we could combine into an oslo.text library, when they are ready to graduate.</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">
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Regards,<br>
Eric Windisch<br>
</font></span><div class="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div><br></div></div>