-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 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). > > 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 > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUZcwOAAoJEC5aWaUY1u5741wH/2B/Pf56YtAaru7jAR9bN7IZ KNY2zkGIDNMZQJWz3DxW7R0myKdmHVqrM/wA+8Lkf0l/ITh1LtiXtRxx5E2sPnJP jef3ODTESooOKGcGOxvKO8tt/Bl4EorJzkX70dyJzlV7fKfZuwCFpZCp73S7npBh BYd5Dfhi+pTyIZvtWSYKJzloJ/BasvKM+pwvlVsV9JIwMNrwwaLx2yDh+D3fltEg bROJooq5J6z/pN19bZ5UkFU2z9lHNI6K6pa1eWLqQdm8WJnNmfmJjiX+vO2wp1z5 7qDsKL/dbHzXfPrBX8MqO9SEvt/jrDS8TeA2tMgAZg8+F5ST1dVHFGxWXJ4eoF4= =2v6F -----END PGP SIGNATURE----- _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
