Excerpts from Michael Still's message of 2013-11-13 13:24:52 -0800: > On Thu, Nov 14, 2013 at 8:20 AM, Eric Windisch <[email protected]> wrote: > > > 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. > > I strongly disagree. It stops projects from syncing with oslo until > they go through the code churn to remove the method. > > > 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'm not sure I see the harm in leaving small but widely used modules > in oslo incubator. If we really want to release everything as a > library, can't we just have a generic catchall one for the small > things? oslo.therest perhaps?
It seems to me that we have two different encodetures in oslo: 1) Useful reusable code. config, logging, db access, etc. 2) Common OpenStack conventions/formats/etc. Our usage of this module is just a level of indirection for all of us to share. I don't mind having a tiny library that makes things more consistent. I suggest that if something is found to be a common OpenStack convention, it can go in a library that we call something clever, like "kevin", or "oslo.common". _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
