On Wed, Nov 13, 2013 at 4:20 PM, Eric Windisch <[email protected]>wrote:
> >> Each project should directly use the standard uuid module or implement > its > >> own helper function to generate uuids if this patch gets in. > >> > >> Any thoughts on this change? Thanks. > > > > > > Unfortunately it looks like that change went through before I caught up > on > > email. Shouldn't we have removed its use in the downstream projects (at > > least integrated projects) before removing it from Oslo? > > I don't think it is a problem to remove the code in oslo first, as > long as no other oslo-incubator code uses it. Projects don't have to > sync the code and could always revert should that they do. > 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. > > However, like Mark, I'm inclined to consider the value of > is_uuid_like. While undoubtedly useful, is one method sufficient to > warrant creating a new top-level module. Waiting for it to hit the > standard library will take quite a long time... > > There are other components of oslo that are terse and questionable as > standalone libraries. For these, it might make sense to aggressively > consider rolling some modules together? > > One clear example would be log.py and log_handler.py, another would be > periodic_task.py and loopingcall.py > 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. Doug > > -- > Regards, > Eric Windisch > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
