[ovirt-devel] Creating a new gerrit flag

[Oved Ourfali]

----- 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
> 

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