<div dir="ltr">Ihar, <div><br></div><div>Reverting patches is unacceptable for Rally project. </div><div>This means that we merged bug and this is epic fail of PTL of project. </div><div><br></div><div><br></div><div>Let's take a look from other side, Ihar would you share with me </div><div>your  password of your email? </div><div>You can believe me I won't do anything wrong with it. </div><div><br></div><div>And "yes" I don't want to trust anybody this is huge amount of work to PTL.</div><div><br></div><div>PTL in such case is bottleneck because he need to check that all 100500+</div><div>subcores are reviewing pieces that they can review and passing +2 only on</div><div>patches that they can actually merge.  </div><div><br></div><div><br></div><div>Let's just automate this stuff.</div><div>Like we have automated CI for testing. </div><div><br></div><div>Best regards,</div><div>Boris Pavlovic  </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 3, 2015 at 2:28 PM, Ihar Hrachyshka <span dir="ltr"><<a href="mailto:ihrachys@redhat.com" target="_blank">ihrachys@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA256<br>
<span class=""><br>
On 06/03/2015 08:29 AM, Boris Pavlovic wrote:<br>
> Guys,<br>
><br>
> I will try to summarize all questions and reply on them:<br>
><br>
</span>> *- Why not splitting repo/plugins?*<br>
<span class="">><br>
> I don't want to make "architectural" decisions based on "social" or<br>
>  "not enough good tool for review" issues.<br>
><br>
> If we take a look at OpenStack that was splited many times:<br>
> Glance, Cinder, ... we will see that there is a log of code<br>
> duplication that can't be removed even after two or even more years<br>
> of oslo effort. As well it produce such issues like syncing<br>
> requirements, requirements in such large bash script like devstack,<br>
>  there is not std installator, it's quite hard to manage and test<br>
> it and so on..<br>
><br>
> That's why I don't think that splitting repo is good<br>
> "architecture" decision - it makes simple things complicated...<br>
><br>
><br>
</span>> *- Why not just trust people*<br>
<span class="">><br>
> People get tired and make mistakes (very often).<br>
<br>
</span>I wouldn't say they make mistakes *too* often. And if there is a<br>
mistake, we always have an option to git-revert and talk to the guy<br>
about it. I believe no one in the neutron team merges random crap, and<br>
I would expect the same from other openstack teams.<br>
<br>
It's also quite natural that people who do more reviews extend their<br>
field of expertise. Do we really want to chase PTLs to introduce a<br>
change into turing-complete-acl-description each time we feel someone<br>
is now ready to start reviewing code from yet another submodule?<br>
<br>
Or consider a case when a patch touches most, if not all submodules,<br>
but applies some very trivial changes, like a new graduated oslo<br>
library being consumed, or python3 adoption changes. Do you want to<br>
wait for a super-core with enough ACL permissions for all those<br>
submodules touched to approve it? I would go the opposite direction,<br>
allowing a single core to merge such a trivial patch, without waiting<br>
for the second one to waste his time reviewing it.<br>
<br>
Core reviewers are not those who are able to put +2 on any patch, but<br>
those who are able to understand where *not* to put it. I would better<br>
allow people themselves to decide where they are capable and where<br>
their expertise ends, and free PTLs from micro-managing the cats.<br>
<br>
So in essence: mistakes are cheap; reputation works; people are<br>
responsible enough; and more ACL fences are evil.<br>
<span class=""><br>
> That's why we have blocking CI system that checks patches,<br>
<br>
</span>Those checks are easy to automate. Trust is not easily formalized though<br>
.<br>
<br>
Ihar<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2<br>
<br>
iQEcBAEBCAAGBQJVbuS9AAoJEC5aWaUY1u57v2wH/iDLvCrebTtTpocZ8a0BFJ7T<br>
ssgjM+1F2JiEuieNg7qRqkdW8fZuMuODc7EnWihjDjfP4OMQkelO2711KSPTCSmT<br>
76RLMQrSHhyB2FO29qu+4bE5uwUV4uutaDyK8IRZpra+nrSoU8dtL6NuTa/csEeU<br>
QbmJBB2UMSXdrQmA6HfzoQV9Dmqk5ePbjzg1HXTFy/AtxCb2DLf2IUmeHqwtqg1o<br>
WoC5ISqoUkRzWx5h1IbV26hhJuGrW6pWjrX50UEFmR/VZwz9T13s7BVE4ReE7mnA<br>
2cIGdFnhaJY/VzD4WEzXRfNXV0qetTJG6w30wktKq6y1mG6q8nm+N6KQ4Onq0FQ=<br>
=DZSF<br>
-----END PGP SIGNATURE-----<br>
<div class="HOEnZb"><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>