Open Stack

On Nov 14, 2014, at 4:31 AM, Ihar Hrachyshka <ihrachys at redhat.com> wrote:

> Signed PGP part
> On 14/11/14 09:14, Flavio Percoco wrote:
> > On 13/11/14 23:25 +0000, Amrith Kumar wrote:
> >> At the suggestion of Doug Hellmann, and relative to a
> >> conversation with him and Flavio at Summit. Doug suggested that I
> >> pose this question on the dev mailing list so someone from OSLO
> >> can communicate the answer to the entire community (rather than
> >> just the private email exchange that we had).
> >>
> >>
> >>
> >> Here’s the situation, I’m using loopingcall.py as an example,
> >> this is not limited to this module but serves as an example.
> >>
> >>
> >>
> >> An OSLO incubator module loopingcall depends on another OSLO
> >> incubator module timeutils.
> >>
> >>
> >>
> >> timeutils has graduated [drum-roll] and is now part of
> >> oslo.utils.
> >>
> >>
> >>
> >> There is also other project code that references timeutils.
> >>
> >>
> >>
> >> So, to handle the graduation of timeutils, the changes I’ll be
> >> making are:
> >>
> >>
> >>
> >> 1.  Remove timeutils from openstack-common.conf
> >>
> >> 2.  Make the project code reference oslo.utils
> >>
> >>
> >>
> >> But what of loopingcall? Should I
> >>
> >>
> >>
> >> a.  Update it and change the import(s) therein to point to
> >> oslo.utils, or
> >>
> >> b.  Sync the oslo-incubator code for loopingcall, picking up all
> >> changes at least upto and including the change in oslo-incubator
> >> that handles the graduation of oslo.utils.
> >>
> >>
> >>
> >> In speaking with Doug and Flavio, (after I submitted copious
> >> amounts of code that did (a)) above, I’ve come to learn that I
> >> chose the wrong answer. The correct answer is (b). This doesn’t
> >> have to be part of the same commit, and what I’ve ended up doing
> >> is this …
> >>
> >>
> >>
> >> c.  Leave timeutils in <project>/openstack/common and let
> >> oslo-incubator depend on it while migrating the project to use
> >> oslo.utils. In a subsequent commit, a sync from oslo-incubator
> >> can happen.
> >>
> >>
> >>
> >> I’d like someone on OSLO to confirm this, and for other projects
> >> whose lead I followed, you may want to address these in the
> >> changes you have in flight or have already merged.
> >>
> >
> > `b` is the right answer there. As a general rule - probably the
> > easiest way to solve the above dilema - people should *never*
> > modify incubator modules in the project. Sticking to this rule
> > will automatically answer the question of how to update, maintain
> > and consume code from oslo-incubator.
> 
> Crazy idea: we should have a bot that -1's all the patches that modify
> oslo-incubator code without being marked by some special tag
> (OsloSync?). We've slipped several local modifications to those files
> before (I know two cases in Neutron, though I hardly monitor all the
> patch queue).

Anyone with energy to put into automating checks like this is welcome to come help us graduate libraries instead. :-)

Doug

> 
> >
> > If there are projects that picked `a` as the right answer, please,
> > update your patches and follow the already well defined workflow
> > for oslo-incubator. Doing otherwise will just make things harder
> > for us who maintain oslo, for stable maintenance and for your own
> > contributors.
> >
> > Amrith, thanks for bringing this up and for updating your patches,
> > I know it's a pain and I appreciate your collaboration there.
> >
> > Cheers, Flavio
> >
> > P.S: Gentle note. Oslo is not an acronym.
> >
> >
> >
> > _______________________________________________ OpenStack-dev
> > mailing list OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev