<div dir="ltr">Julien,<div><br></div><div>If I were on you shoes I would pick words more carefully. </div><div><br></div><div>When you are saying: </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="im" style="font-size:12.8000001907349px">> Reverting patches is unacceptable for Rally project.</span><span class="im" style="font-size:12.8000001907349px"><br></span><span style="font-size:12.8000001907349px">Then you have a more serious problem than the rest of OpenStack.</span></blockquote><div><br></div><div>"you" means Rally community which is quite large. </div><div><a href="http://stackalytics.com/?release=liberty&metric=commits&project_type=openstack&module=rally">http://stackalytics.com/?release=liberty&metric=commits&project_type=openstack&module=rally</a><br></div><div><br></div><div><br></div><div>And I don't understand "what" so serious problem we have.</div><div>We were not able to do reverts so  we build CI that doesn't allow us to break master</div><div> so we don't need to do reverts. I really don't see here any big problems. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="im" style="font-size:12.8000001907349px">> This means that we merged bug and this is epic fail of PTL of project.</span><span class="im" style="font-size:12.8000001907349px"><br></span><span style="font-size:12.8000001907349px">Your code is already full of bugs and misfeatures, like the rest of the<br></span><span style="font-size:12.8000001907349px">software. That's life.</span></blockquote><div><br></div><div>I was talking about reverting patches. And I believe the process is broken </div><div>if you need to revert patches. It means that core team is not enough team </div><div>or CI is not enough good. </div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8000001907349px">If you're having trust issues, good luck maintaining any large-scale<br></span><span style="font-size:12.8000001907349px">successful (open source) project. This is terrible management and leads<br></span><span style="font-size:12.8000001907349px">to micro-managing tasks and people, which has never build something<br></span><span style="font-size:12.8000001907349px">awesome.</span></blockquote><div><br></div><div>I don't believe even my self, because I am human and I make mistakes. </div><div>My goal on the PTL position is to make such process that stops "human"</div><div>mistakes before they land in master. In other words  everything should be</div><div>automated and pre not post checked. </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 4:00 PM, Thierry Carrez <span dir="ltr"><<a href="mailto:thierry@openstack.org" target="_blank">thierry@openstack.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So yeah, that's precisely what we discussed at the cross-project<br>
workshop about In-team scaling in Vancouver (led by Kyle and myself).<br>
For those not present, I invite you to read the notes:<br>
<br>
<a href="https://etherpad.openstack.org/p/liberty-cross-project-in-team-scaling" target="_blank">https://etherpad.openstack.org/p/liberty-cross-project-in-team-scaling</a><br>
<br>
The conclusion was to explore splitting review areas and building trust<br>
relationships. Those could happen:<br>
<br>
- along architectural lines (repo splits)<br>
- along areas of expertise with implicit trust to not review anything else<br>
<br>
... which is precisely what you seem to oppose.<br>
<span class=""><br>
Boris Pavlovic wrote:<br>
> *- Why not splitting repo/plugins?*<br>
><br>
</span><span class="">>   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: Glance,<br>
> Cinder, ...<br>
>   we will see that there is a log of code duplication that can't be<br>
> removed even after<br>
>   two or even more years of oslo effort. As well it produce such issues<br>
> 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 it<br>
> and so on..<br>
><br>
>   That's why I don't think that splitting repo is good "architecture"<br>
> decision - it makes<br>
>    simple things complicated...<br>
<br>
</span>I know we disagree on that one, but I don't think monolithic means<br>
"simpler". Having smaller parts that have a simpler role and explicit<br>
contracts to communicate with other pieces is IMHO better and easier to<br>
maintain.<br>
<br>
We shouldn't split repositories when it only results in code<br>
duplication. But whenever we can isolate something that could have a<br>
more dedicated maintenance team, I think that's worth exploring as a<br>
solution to the review scaling issue.<br>
<span class=""><br>
> *- Why not just trust people*<br>
><br>
</span><span class="">> People get tired and make mistakes (very often).<br>
> That's why we have blocking CI system that checks patches,<br>
> That's why we have rule 2 cores / review (sometimes even 3,4,5...)...<br>
<br>
</span>It's not because "we don't trust people" that we have the 2-core rule.<br>
Core reviewers check the desirability and quality of implementation. By<br>
default we consider that if 2 of those agree that a change is sane, it<br>
probably is. The CI system checks something else, and that is that you<br>
don't break everyone or introduce a regression. So you shouldn't be able<br>
to "introduce a bug" that would be so serious that a simple revert would<br>
still be embarrassing. If you can, then you should work on your tests.<br>
<br>
I think it's totally fine to give people the ability to +2/approve<br>
generally, together with limits on where they are supposed to use that<br>
power. They will be more careful as to what they approve this way. For<br>
corner cases you can revert.<br>
<br>
As an example, Ubuntu development has worked on that trust model for<br>
ages. Once you are a developer, you may commit changes to any package in<br>
the distro. But you're supposed to use that power wisely. You end up<br>
staying away from risky packages and everything you don't feel safe to<br>
approve.<br>
<br>
If you can't trust your core reviewers to not approve things that are<br>
outside their comfort zone, I'd argue they should not be core reviewers<br>
in the first place.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Thierry Carrez (ttx)<br>
</font></span><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>