I see Jordan's opinion here and I also faced this situation before. I proposed a hacking patch [1] to notify wrong usage of Tempest methods to projects and I saw some users of these methods didn't know the definition of stable interfaces of Tempest. We always face this issue on developments which change *internal* methods of Tempest.
2017-02-26 10:13 GMT-08:00 Andrea Frittoli <andrea.fritt...@gmail.com>: > > Scenario tests will go through a significant number of changes as part of > the refactor and if every change risks to break someone's gate job it won't > work. > I propose we proceed as follows: > - identify projects that import from tempest.scenario > - send a notification to the ML about the changes that are going to happen > - help the affected teams to identify a way decouple them from tempest > scenario code - most likely copy the relevant code in-tree > - meanwhile continue to work on patches for scenario tests but do not merge > them yet Yeah, this approach is very nice to land patches softly. Users can find solutions if facing this issue on the own gate. > This process shouldn't take long and be rather straight forward. > > I already have some data from codesearch, I will send out the e-mail > tomorrow. ++, thanks for your leadership. Thanks Ken Ohmichi --- [1]: https://review.openstack.org/#/c/328651 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
