On 11/14/2014 03:31 AM, Ihar Hrachyshka wrote:
-----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).
We had this problem a lot in Cinder in the past. With education and monitoring from the Cores we have been able to avoid it. The idea of monitoring for such commits is a good idea. I wonder, however, if there is a way to do it with a hacking check?


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


_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to