<div dir="ltr">Why not use +1 on verified? That way the patch owner can wait till the code review process is over, mark it as verified, wait for CI and then submit.<div>It doesn't really give much added value to the code reviewers whether it's marked as verified or not</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 20, 2016 at 10:26 PM, Sandro Bonazzola <span dir="ltr"><<a href="mailto:sbonazzo@redhat.com" target="_blank">sbonazzo@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><p dir="ltr"></p>
<p dir="ltr">Il 20/Nov/2016 17:25, "Nir Soffer" <<a href="mailto:nsoffer@redhat.com" target="_blank">nsoffer@redhat.com</a>> ha scritto:<br>
><br>
> On Sun, Nov 20, 2016 at 5:39 PM, Yedidyah Bar David <<a href="mailto:didi@redhat.com" target="_blank">didi@redhat.com</a>> wrote:<br>
> > On Sun, Nov 20, 2016 at 5:06 PM, Barak Korren <<a href="mailto:bkorren@redhat.com" target="_blank">bkorren@redhat.com</a>> wrote:<br>
> >> Hi all,<br>
> >><br>
> >> Perhaps the main purpose of CI, is to prevent braking code from<br>
> >> getting merged into the stable/master branches. Unfortunately our CI<br>
> >> is not there yet, and one of the reasons for that is that we do large<br>
> >> amount of our CI tests only _after_ the code is merged.<br>
> >><br>
> >> The reason for that is that when balancing through, but time<br>
> >> consuming, tests (e.g. enging build with all permutations) v.s. faster<br>
> >> but more basic ones (e.g. "findbugs" and single permutation build), we<br>
> >> typically choose the faster tests to be run per-patch-set and leave<br>
> >> the through testing to only be run post-merge.<br>
> >><br>
> >> We'd like to change that and have the through tests also run before<br>
> >> merge. Ideally we would like to just hook stuff to the "submit"<br>
> >> button, but Gerrit doesn't allow one to do that easily. So instead<br>
> >> we'll need to adopt some kind of flag to indicate we want to submit<br>
> >> and have Jenkins<br>
> >> "click" the submit button on our behalf if tests pass.<br>
> >><br>
> >> I see two options here:<br>
> >> 1. Use Code-Review+2 as the indicator to run "heavy" CI and merge.<br>
><br>
> This is problematic. For example in vdsm we have 5 maintainers with<br>
> +2, and 4 maintainers with commit right, but only 2 are commenting<br>
> regularly.<br>
><br>
> >> 2. Add an "approve" flag that maintainers can set to +1 (This is<br>
> >> what OpenStack is doing).<br>
><br>
> This seems better.<br>
><br>
> But there is another requirement - maintainer should be able to commit<br>
> even if jenkins fails. Sometimes the CI is broken, or there are flakey tests<br>
> breaking the build, and some jobs are failing regularly (check-merged)<br>
> and I don't want to wait for it.</p>
</div></div><p dir="ltr">Either disable the jobs or fix them. Having jobs consitently failing and just ignore them is just a waste of resources. <br><br></p><div class="HOEnZb"><div class="h5">
<p dir="ltr">><br>
> Today we can override the CI vote and commit, if we keep it as is I don't<br>
> see any problem with this change.<br>
><br>
> Nir<br>
> ______________________________<wbr>_________________<br>
> Devel mailing list<br>
> <a href="mailto:Devel@ovirt.org" target="_blank">Devel@ovirt.org</a><br>
> <a href="http://lists.ovirt.org/mailman/listinfo/devel" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br></p>
</div></div><br>______________________________<wbr>_________________<br>
Devel mailing list<br>
<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br></blockquote></div><br></div>