On Wed, Nov 13, 2013 at 4:24 PM, Michael Still <mi...@stillhq.com> wrote:
> On Thu, Nov 14, 2013 at 8:20 AM, Eric Windisch <e...@cloudscaling.com> > 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? > Every project eventually grows a utils module, right? :-) Seriously, we'll release things in large enough chunks that they are worth maintaining on their own, while sticking to a logical grouping of features. Not everything is going to be as big as oslo.messaging, but most of the libraries won't be as small as oslo.version either. Doug > > Michael > > -- > Rackspace Australia > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev