Open Stack

Fuelers

I am writing that we had a really sad incident - we noticed that after we
merged upstream keystone module we lost modifications (Change-Id:
Idfe4b54caa0d96a93e93bfff12d8b6216f83e2f1
<https://review.openstack.org/#/q/Idfe4b54caa0d96a93e93bfff12d8b6216f83e2f1,n,z>)
for memcached dogpile driver which are crucial for us. And here I can see 2
problems:

1) how can we ensure that we did not lose anything else?
2) how can we ensure that this will never happen again?

Sadly, it seems that the first question implies that we recheck all the
upstream merge/adaptation commits by hand and check that we did not lose
anything.

Regarding question number 2 we do already have established process for
upstream code merge:
http://docs.mirantis.com/fuel-dev/develop/module_structure.html#contributing-to-existing-fuel-library-modules.
It seems that this process had  not been established when keystone code was
reviewed. I see two ways here:

1) We should enforce code review workflow and specifically say that
upstream merges can be accepted only after we have 2 '+2s' from core
reviewers after they recheck that corresponding change does not introduce
any regressions.
2) We should speed up development of some modular testing framework that
will check that corresponding change affects only particular pieces. It
seems much easier if we split deployment into stages (oh my, I am again
talking about granular deployment feature) and each particular commit
affects only one of the stages, so that we can see the difference and catch
regressions eariler.





-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
45bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com <http://www.mirantis.ru/>
www.mirantis.ru
vkuklin at mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141119/95cb0b60/attachment.html>