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

=20 =20 ----- Original Message ----- > From: "Eyal Edri" <eedri(a)redhat.com&gt; > To: devel(a)ovirt.org > Cc: "Oved Ourfali" <ovedo(a)redhat.com&gt;, "infra" <infra(a)ovirt.org&gt; > Sent: Wednesday, December 10, 2014 10:40:47 AM > Subject: Re: [ovirt-devel] Creating a new gerrit flag >=20 >=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 > > Sent: Wednesday, December 10, 2014 8:30:30 AM > > 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: devel(a)ovirt.org > > > Sent: Tuesday, December 9, 2014 7:02:44 PM > > > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > >=20 > > > On 12/09, Oved Ourfali wrote: > > > >=20 > > > >=20 > > > > ----- Original Message ----- > > > > > From: "David Caro" <dcaroest(a)redhat.com&gt; > > > > > To: "Oved Ourfali" <ovedo(a)redhat.com&gt; > > > > > Cc: "Sven Kieske" <s.kieske(a)mittwald.de&gt;, devel(a)ovirt.org > > > > > Sent: Tuesday, December 9, 2014 3:40:30 PM > > > > > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > > > >=20 > > > > > On 12/09, Oved Ourfali wrote: > > > > > >=20 > > > > > >=20 > > > > > > ----- Original Message ----- > > > > > > > From: "Sven Kieske" <s.kieske(a)mittwald.de&gt; > > > > > > > To: devel(a)ovirt.org > > > > > > > Sent: Tuesday, December 9, 2014 3:21:43 PM > > > > > > > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > On 09/12/14 13:47, Oved Ourfali wrote: > > > > > > > > safe up to 95% or so. > > > > > > >=20 > > > > > > > You just made up that number. > > > > > > > I don't really understand why you would want > > > > > > > to downgrade your code quality by circumventing tests. > > > > > > >=20 > > > > > > > Maybe someone can elaborate on this a bit? > > > > > > >=20 > > > > > >=20 > > > > > > It doesn't downgrade the code quality. > > > > > > It is just a way to ensure developers can both merge changes,=

> > > > > > do > > > > > > it > > > > > > as > > > > > > safely as possible without relying on post-submit tools. > > > > > > The number is indeed invented... as I don't have real statist=

> > > > > > but > > > > > > it > > > > > > comes to say that it would be safe most of the time. > > > > > > After the patch is merged, if CI will fail, it is the > > > > > > responsibility > > > > > > of > > > > > > the > > > > > > developer to check that out and fix that. > > > > >=20 > > > > > This thread was started to avoid getting to that point, as gett=

> > > > > failed patch inside the code means breaking all the other tests=

> > > > > run on top of it and that blocks all the development, not only =

> > > > > specific patch. > > > > >=20 > > > >=20 > > > > The issue that started the discussion was an issue in which there=

> > > > Tests "-1" flag, and it was ignored. > > > > My suggestion will enforce that it won't be ignored. > > > > In more rare cases, in which the rebase is the source of the tests > > > > issue, > > > > then you'll find about it later. > > >=20 > > > I started the discussion, and I started it because a developer > > > complained about not being able to merge a patch because it was > > > failing the tests due to an already merged patch that was making all > > > the builds to fail. And was trying to get a solution to avoid getti=

> > > to that point where a patch is merged while breaking the tests. > > >=20 > > >=20 > > > So in summary, you are suggestion this: > > >=20 > > > Creating a new flag 'tested' with values +1, 0 and -1 that only jen=

> > > and managers can set > > >=20 > > > Block form submitting any patches that have a -1 > > >=20 > > > Carry the value of that flag to following patches only if the flag =

> > > -1 > > >=20 > >=20 >=20 > +1, we need a way to block bad patches from being merged, even with a r=

> in gerrit. > going forward we're planning a few changes to the way jenkins jobs are =

> ovirt ci, which will help > reduce noise and imrove resources usages. >=20 > 1. moving into a flow process, where critical jobs like unit tests/chec=

> will run first and only then other heavy jobs will run > (integration/rpms/findbugs) =20 This is already implemented in vdsm for few months - running "make check" will run the fast tests first and will not run the slower tests if a fast=

failed.

=20 Nir _______________________________________________ Infra mailing list Infra(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/infra

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUiF/YAAoJEEBxx+HSYmnD7HcH+wRFNKrzqUS/JO7f5YQCZxu3 4U4D/gKyURIPI0ghdf8vmEWbBQq4wKanKaO533rPuu9ZhuJRNOLhHCBA+I7rVdvL eyGN4E0gidWDb5tBtp5PaoRauEs7tC5DGMH0ZzyskfrBZeyUUjtbbmsCnAM7noya gx4nQh7lbE0e28ZbOt2GonAPVVkoYvQ+msd8v9/pG7Hks+KkO+24BuTfPRecSl3c qslRw09jBJoTdIuO4irfVqtUO4engLckFu02Q3ID5Q+qsXscG+AGGSvSzOVLtr3V 1WXalQ1qNd15+MB0q6n4XgQamRzsANQ8glcuSIdWeR2b96xuwrjz1MZeiSwUXdE= =AbWb -----END PGP SIGNATURE-----