Re: [ovirt-devel] Creating a new gerrit flag

=20 =20 ----- Original Message ----- > From: "Oved Ourfali" <ovedo(a)redhat.com&gt; > To: "David Caro" <dcaroest(a)redhat.com&gt; > Cc: infra(a)ovirt.org, devel(a)ovirt.org > Sent: Tuesday, December 9, 2014 2:27:14 PM > Subject: Re: [ovirt-devel] Creating a new gerrit flag >=20 > top posting: > How about the following flow: > 1. You push a patch to gerrit. > 2. You need +1 on Testing in order to merge it. > 3. You have +1/-1 on the Tests if finished successfully/failed > 4. You find out you need to rebase. > 5. The rebase copies the result of the Tests of the previous patch-set.=

> it was +1, it remains +1 and you can merge (assuming you have +2 on CR)=

> it was -1 then you need to wait for the CI to finish, and it might set =

> +1. >=20 > Does that make sense? =20 Yes, but only if you used rebase button and automatic rebase worked. In case of merge conflict you will need to wait after rebase for tests.

=20 >=20 > ----- Original Message ----- > > From: "Oved Ourfali" <ovedo(a)redhat.com&gt; > > To: "David Caro" <dcaroest(a)redhat.com&gt; > > Cc: devel(a)ovirt.org, infra(a)ovirt.org > > Sent: Tuesday, December 9, 2014 1:13:57 PM > > Subject: Re: [ovirt-devel] Creating a new gerrit flag > >=20 > >=20 > >=20 > > ----- Original Message ----- > > > From: "David Caro" <dcaroest(a)redhat.com&gt; > > > To: "Oved Ourfali" <ovedo(a)redhat.com&gt; > > > Cc: infra(a)ovirt.org, devel(a)ovirt.org > > > Sent: Tuesday, December 9, 2014 12:12:19 PM > > > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > >=20 > > > On 12/09, Oved Ourfali wrote: > > > > What happens when rebasing? > > > > We can't afford waiting for tests to run on each rebase... as we =

> > > > end > > > > up rebasing forever. > > >=20 > > > For now we will have to, all the code that is going to be merged mu=

> > > be tested as it is going to be merged, that means running the tests=

> > > the last rebase too. > > >=20 > > > In the future there are plans on using a gating system like zuul, so > > > zuul will be the one monitoring the tests and merging when passes, =

> > > you will just add the flag, and that will trigger the gate, that ru=

> > > the tests and merged the patch. > > >=20 > > > It's unlikely that you'll have to wait forever, but there's nothing > > > avoiding you doing that (right now even). > > >=20 > > > I'd like to put emphasis again on differentiating between tests that > > > are fast, that should run on each patch and tests that are slow, th=

> > > should run on each merge. That will improve the feedback times. > > >=20 > >=20 > > So let's apply that in the future. > > For now the amount of merges done is enormous, and it will be impossi=

> > get things merged on a reasonable time. > > Again, I'm not against testing, but it should be done the right way... > >=20 > > > >=20 > > > > ----- Original Message ----- > > > > > From: "David Caro" <dcaroest(a)redhat.com&gt; > > > > > To: devel(a)ovirt.org, infra(a)ovirt.org > > > > > Sent: Tuesday, December 9, 2014 11:43:04 AM > > > > > Subject: [ovirt-devel] Creating a new gerrit flag > > > > >=20 > > > > > Hi! > > > > >=20 > > > > > e have been having an issue with gerrit patches being merged be=

> > > > > jenkins ran any tests on them, to avoid it from happening again=

> > > > > propose creating a new gerrit flag (Tests) with the following > > > > > specifics: > > > > >=20 > > > > >=20 > > > > > +1 - Tests passed/overrided > > > > > 0 - Tests pending > > > > > -1 - Tests broken > > > > >=20 > > > > > where +1 is required to submit, +1 is set by jenkins when > > > > > passing the tests and -1 is set by jenkins in case it breaks any > > > > > tests. The +1 flag can be set also by maintainers to allow over=

> > > > > the process. > > > > >=20 > > > > > That way all the tests will be blocked until someone (hopefully > > > > > jenkins) adds the +1 flag, but if the maintainer wants to overr=

> > > > > the > > > > > value, she just has to set that flag herself. > > > > >=20 > > > > >=20 > > > > > What do you think? > > > > >=20 > > > > >=20 > > > > > -- > > > > > David Caro > > > > >=20 > > > > > Red Hat S.L. > > > > > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > > > >=20 > > > > > Tel.: +420 532 294 605 > > > > > Email: dcaro(a)redhat.com > > > > > Web: www.redhat.com > > > > > RHT Global #: 82-62605 > > > > >=20 > > > > > _______________________________________________ > > > > > Devel mailing list > > > > > Devel(a)ovirt.org > > > > > http://lists.ovirt.org/mailman/listinfo/devel > > >=20 > > > -- > > > David Caro > > >=20 > > > Red Hat S.L. > > > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > >=20 > > > Tel.: +420 532 294 605 > > > Email: dcaro(a)redhat.com > > > Web: www.redhat.com > > > RHT Global #: 82-62605 > > >=20 > > > _______________________________________________ > > > Devel mailing list > > > Devel(a)ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/devel > > _______________________________________________ > > Devel mailing list > > Devel(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/devel > >=20 > _______________________________________________ > Devel mailing list > Devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel >=20

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUhu3LAAoJEEBxx+HSYmnDdP0H/3RLp7CSIAP9HgffU/hBC/G2 wEZzBNIgaeeZ4wkjaPjN8tijl7iXX+/1f3CsIZNfrCEkl5b+gd9MZYsoczPGuXxX p8VuYM0Z/MgBNrz6b8p72wAGD3NuaK/UDnlbE7hsaYVb72t2SBBpYbFAvi6h/OWf GfteLxFI6NH3EF6j0u08wE2msM4270G6dh9D6h3nvUzyYAoNUaGFpZKlGGuKV9XC tcuH+i+GGyzg6QF8jBVgLDYKLi2ZYMhfKJpzTNXI8gkcAJp6HRgVi3TrIS5xNpp2 +f688J+oH4c+EZgV/DPu93r4f+OzHnhfK0BNjGX4G0HqYx8la4QN+f2GyaPdgKs= =Oqyk -----END PGP SIGNATURE-----