On Nov 14, 2014, at 4:31 AM, Ihar Hrachyshka <[email protected]> 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 [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 _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
