[ovirt-devel] Creating a new gerrit flag

Wed Dec 10 08:40:47 UTC 2014

----- Original Message -----
> From: "Oved Ourfali" <ovedo at redhat.com>
> To: "David Caro" <dcaroest at redhat.com>
> Cc: devel at ovirt.org
> Sent: Wednesday, December 10, 2014 8:30:30 AM
> Subject: Re: [ovirt-devel] Creating a new gerrit flag
> 
> 
> 
> ----- Original Message -----
> > From: "David Caro" <dcaroest at redhat.com>
> > To: "Oved Ourfali" <ovedo at redhat.com>
> > Cc: devel at ovirt.org
> > Sent: Tuesday, December 9, 2014 7:02:44 PM
> > Subject: Re: [ovirt-devel] Creating a new gerrit flag
> > 
> > On 12/09, Oved Ourfali wrote:
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "David Caro" <dcaroest at redhat.com>
> > > > To: "Oved Ourfali" <ovedo at redhat.com>
> > > > Cc: "Sven Kieske" <s.kieske at mittwald.de>, devel at 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 at mittwald.de>
> > > > > > To: devel at 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.
> > > 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.
> > 
> > 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 getting
> > to that point where a patch is merged while breaking the tests.
> > 
> > 
> > So in summary, you are suggestion this:
> > 
> > Creating a new flag 'tested' with values +1, 0 and -1 that only jenkins
> > and managers can set
> > 
> > Block form submitting any patches that have a -1
> > 
> > Carry the value of that flag to following patches only if the flag was
> > -1
> > 
> 

+1, we need a way to block bad patches from being merged, even with a rebase in gerrit.
going forward we're planning a few changes to the way jenkins jobs are run on ovirt ci, which will help 
reduce noise and imrove resources usages.

1. moving into a flow process, where critical jobs like unit tests/checkstyle will run first and only then other heavy jobs will run (integration/rpms/findbugs)
2. using gating system like zuul to do the merge after verification of sanity jobs automatically.

these will take time of course and will be done gradually.

> And carry on also +1 in case of gerrit rebases.
> 
> > That way if any of the previous patches failed any test you won't be
> > able to merge it unless a maintainer accepts or the tests pass. But if
> > your previous patchset passed, you will be able to merge right away.
> > 
> > Is that correct?
> > 
> > Just for comparison, right now anyone with submit privileges can
> > submit any patch rebasing and submitting before jenkins gives it's
> > review. I don't see a real advantage, as right now only maintainers
> > should be able to submit, so the people doing the submit already know
> > that the tests are failing and ignoring it, your solution will not
> > prevent them from keep ignoring them.

> > 
> > 
> > > 
> > > 
> > > > > 
> > > > > > --
> > > > > > 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 at ovirt.org
> > > > > > http://lists.ovirt.org/mailman/listinfo/devel
> > > > > _______________________________________________
> > > > > Devel mailing list
> > > > > Devel at 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 at redhat.com
> > > > Web: www.redhat.com
> > > > RHT Global #: 82-62605
> > > > 
> > 
> > --
> > David Caro
> > 
> > Red Hat S.L.
> > Continuous Integration Engineer - EMEA ENG Virtualization R&D
> > 
> > Tel.: +420 532 294 605
> > Email: dcaro at redhat.com
> > Web: www.redhat.com
> > RHT Global #: 82-62605
> > 
> > _______________________________________________
> > Devel mailing list
> > Devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel