[openstack-dev] [oslo] The right (and the wrong) way of handling module imports in oslo-incubator
Ihar Hrachyshka
ihrachys at redhat.com
Fri Nov 14 09:31:58 UTC 2014
-----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 OpenStack-dev at lists.openstack.org
> 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-----
More information about the OpenStack-dev
mailing list