=20 =20 ----- Original Message -----
From: "David Caro" <dcaroest@redhat.com> To: "Oved Ourfali" <ovedo@redhat.com> Cc: "Sven Kieske" <s.kieske@mittwald.de>, devel@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@mittwald.de> To: devel@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, 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. =20 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. =20 =20 The issue that started the discussion was an issue in which there was a T= ests "-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,=
--rf72Gf+bfLC8kxKs Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 12/09, Oved Ourfali wrote: 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 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.
=20 =20
=20
-- Mit freundlichen Gr=FC=DFen / Regards =20 Sven Kieske =20 Systemadministrator Mittwald CM Service GmbH & Co. KG K=F6nigsberger Stra=DFe 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Gesch=E4ftsf=FChrer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplement=E4rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel =20 -- David Caro =20 Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D =20 Tel.: +420 532 294 605 Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605 =20
--=20 David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420 532 294 605 Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605 --rf72Gf+bfLC8kxKs Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUhys0AAoJEEBxx+HSYmnDrusIAJFzntcs1DEL85J2XT+avKrb FG9/LjSx+ZnFCleG6KxGXOYB6dngFIan1obc57IinhCp80WJLP2BCInbSbqKW6F7 Y/SHQEi/QZ1gELi649v72+ShGXGRVSkiud50CSPCEkZh8T2F7v5rhB2kVoYT3h5f gC4wcAIfy0QarMIs/rj5J7aC3AMjX8hqF5XgoKhW3Z71E1UxOA3TqiewXknKSGtS wCVHc0plE4hemS7ohp1uHxtJeFOgYJ33CzuCMPmnIiAmEmRwMk2dBSLdnrNJ8k/K ZRq2M9eTqnlRr15kg4qfmXQM1XGLoZ5jqlI5acEPE+/SUIgFLU+SoJoQ2GJer3U= =dybC -----END PGP SIGNATURE----- --rf72Gf+bfLC8kxKs--