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 ----- 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 > > On 12/09, Oved Ourfali wrote: > > > > > > ----- 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 > > > > > > On 12/09, Oved Ourfali wrote: > > > > > > > > > > > > ----- 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 > > > > > > > > > > > > > > > > > > > > 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(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 > > > > > -- > 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 _______________________________________________ Devel mailing list Devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/devel