----- Original Message -----
From: "Oved Ourfali" <ovedo(a)redhat.com>
To: "David Caro" <dcaroest(a)redhat.com>
Cc: devel(a)ovirt.org
Sent: Tuesday, December 9, 2014 3:41:47 PM
Subject: Re: [ovirt-devel] Creating a new gerrit flag
----- Original Message -----
> From: "David Caro" <dcaroest(a)redhat.com>
> To: "Oved Ourfali" <ovedo(a)redhat.com>
> Cc: "Sven Kieske" <s.kieske(a)mittwald.de>, devel(a)ovirt.org
> Sent: Tuesday, December 9, 2014 3:40:30 PM
> Subject: Re: [ovirt-devel] Creating a new gerrit flag
>
> On 12/09, Oved Ourfali wrote:
> >
> >
> > ----- Original Message -----
> > > From: "Sven Kieske" <s.kieske(a)mittwald.de>
> > > To: devel(a)ovirt.org
> > > Sent: Tuesday, December 9, 2014 3:21:43 PM
> > > Subject: Re: [ovirt-devel] Creating a new gerrit flag
> > >
> > >
> > >
> > > On 09/12/14 13:47, Oved Ourfali wrote:
> > > > safe up to 95% or so.
> > >
> > > You just made up that number.
> > > I don't really understand why you would want
> > > to downgrade your code quality by circumventing tests.
> > >
> > > Maybe someone can elaborate on this a bit?
> > >
> >
> > It doesn't downgrade the code quality.
> > It is just a way to ensure developers can both merge changes, and do it
> > as
> > safely as possible without relying on post-submit tools.
> > The number is indeed invented... as I don't have real statistics, 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.
>
> This thread was started to avoid getting to that point, as getting a
> failed patch inside the code means breaking all the other tests that
> run on top of it and that blocks all the development, not only that
> specific patch.
>
The issue that started the discussion was an issue in which there was a Tests
"-1" flag, and it was ignored.
+1. Patches which fail jenkins jobs shouldn't be merged - this should be blocked imo.
However, manual triggered jobs should get higher priority (if possible) on the jobs
queue in order to overcome possible delays in merge of urgent patches.
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.
> >
> > > --
> > > Mit freundlichen Grüßen / Regards
> > >
> > > Sven Kieske
> > >
> > > Systemadministrator
> > > Mittwald CM Service GmbH & Co. KG
> > > Königsberger Straße 6
> > > 32339 Espelkamp
> > > T: +49-5772-293-100
> > > F: +49-5772-293-333
> > >
https://www.mittwald.de
> > > Geschäftsführer: Robert Meyer
> > > St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad
> > > Oeynhausen
> > > Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad
> > > Oeynhausen
> > > _______________________________________________
> > > 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
>
> --
> David Caro
>
> Red Hat S.L.
> Continuous Integration Engineer - EMEA ENG Virtualization R&D
>
> Tel.: +420 532 294 605
> Email: dcaro(a)redhat.com
> Web:
www.redhat.com
> RHT Global #: 82-62605
>
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel