--I33OQG5IFrqF2BWt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! e have been having an issue with gerrit patches being merged before jenkins ran any tests on them, to avoid it from happening again I propose creating a new gerrit flag (Tests) with the following specifics: +1 - Tests passed/overrided 0 - Tests pending -1 - Tests broken where +1 is required to submit, +1 is set by jenkins when passing the tests and -1 is set by jenkins in case it breaks any tests. The +1 flag can be set also by maintainers to allow overriding the process. That way all the tests will be blocked until someone (hopefully jenkins) adds the +1 flag, but if the maintainer wants to override the value, she just has to set that flag herself. What do you think? --=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 --I33OQG5IFrqF2BWt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUhsQoAAoJEEBxx+HSYmnDhEAH/jWxTaroG11HCl6Ke547iHXl JS8sr8OF2Vc/D4iNgkopb+ZAM67tsT2DP/q3BtBLz34LlWiIiTgNOmW9Gve+0osM kXzyeTc2ZcyjCF2nvCazZm1hC0WKtgERGfc6wmULyUBgYySF9X0mznNdoWRANCfu CKreZx9KqfiSjGWXsEfog5ETJSX+luolpHzYi0nd9ZLuHKm76Edqn9b6X+CVewS5 Ev0vGmt/qdUDwM3sSPmp4hFVyGBQ/1vvnFgqvSSCp1WwEuFsyM7ctMKtsE0IotrB Tvwc2B3TWTpbKVTsaaiHSAjkRjiqiR6j4h5sEKagBUHhATxdq+7Z3jYZHM0Fn0I= =ZGaS -----END PGP SIGNATURE----- --I33OQG5IFrqF2BWt--
----- Original Message -----
From: "David Caro" <dcaroest@redhat.com> To: devel@ovirt.org, infra@ovirt.org Sent: Tuesday, December 9, 2014 10:43:04 AM Subject: [ovirt-devel] Creating a new gerrit flag
Hi!
e have been having an issue with gerrit patches being merged before jenkins ran any tests on them, to avoid it from happening again I propose creating a new gerrit flag (Tests) with the following specifics:
+1 - Tests passed/overrided 0 - Tests pending -1 - Tests broken
where +1 is required to submit, +1 is set by jenkins when passing the tests and -1 is set by jenkins in case it breaks any tests. The +1 flag can be set also by maintainers to allow overriding the process.
That way all the tests will be blocked until someone (hopefully jenkins) adds the +1 flag, but if the maintainer wants to override the value, she just has to set that flag herself.
What do you think?
Looks good, but there is a scenario which worries me a bit. It happened in the past times that an otherwise good and working patch failed the tests because, for example, pep8 or pyflakes became stricter about the code formatting. Can the maintainer override such a -1 from failed tests in that case? (probably yes, but worth asking) Thanks, -- Francesco Romani RedHat Engineering Virtualization R & D Phone: 8261328 IRC: fromani
----- Original Message -----
From: "Francesco Romani" <fromani@redhat.com> To: "David Caro" <dcaroest@redhat.com> Cc: infra@ovirt.org, devel@ovirt.org Sent: Tuesday, December 9, 2014 11:48:00 AM Subject: Re: [ovirt-devel] Creating a new gerrit flag
----- Original Message -----
From: "David Caro" <dcaroest@redhat.com> To: devel@ovirt.org, infra@ovirt.org Sent: Tuesday, December 9, 2014 10:43:04 AM Subject: [ovirt-devel] Creating a new gerrit flag
Hi!
e have been having an issue with gerrit patches being merged before jenkins ran any tests on them, to avoid it from happening again I propose creating a new gerrit flag (Tests) with the following specifics:
+1 - Tests passed/overrided 0 - Tests pending -1 - Tests broken
where +1 is required to submit, +1 is set by jenkins when passing the tests and -1 is set by jenkins in case it breaks any tests. The +1 flag can be set also by maintainers to allow overriding the process.
That way all the tests will be blocked until someone (hopefully jenkins) adds the +1 flag, but if the maintainer wants to override the value, she just has to set that flag herself.
What do you think?
Looks good, but there is a scenario which worries me a bit.
It happened in the past times that an otherwise good and working patch failed the tests because, for example, pep8 or pyflakes became stricter about the code formatting.
Can the maintainer override such a -1 from failed tests in that case? (probably yes, but worth asking)
If a test fails on this, it will fail on all patches that will follow as well, so I don't think it's a bad requirement that you need to fix the underlying issues for patches to be merged. Without running tests you don't have any good wya to make sure a patch is 'good'.
Thanks,
-- Francesco Romani RedHat Engineering Virtualization R & D Phone: 8261328 IRC: fromani _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
What happens when rebasing? We can't afford waiting for tests to run on each rebase... as we might end up rebasing forever. ----- Original Message -----
From: "David Caro" <dcaroest@redhat.com> To: devel@ovirt.org, infra@ovirt.org Sent: Tuesday, December 9, 2014 11:43:04 AM Subject: [ovirt-devel] Creating a new gerrit flag
Hi!
e have been having an issue with gerrit patches being merged before jenkins ran any tests on them, to avoid it from happening again I propose creating a new gerrit flag (Tests) with the following specifics:
+1 - Tests passed/overrided 0 - Tests pending -1 - Tests broken
where +1 is required to submit, +1 is set by jenkins when passing the tests and -1 is set by jenkins in case it breaks any tests. The +1 flag can be set also by maintainers to allow overriding the process.
That way all the tests will be blocked until someone (hopefully jenkins) adds the +1 flag, but if the maintainer wants to override the value, she just has to set that flag herself.
What do you think?
-- 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
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
----- Original Message -----
From: "Oved Ourfali" <ovedo@redhat.com> To: "David Caro" <dcaroest@redhat.com> Cc: infra@ovirt.org, devel@ovirt.org Sent: Tuesday, December 9, 2014 11:52:11 AM Subject: Re: [ovirt-devel] Creating a new gerrit flag
What happens when rebasing? We can't afford waiting for tests to run on each rebase... as we might end up rebasing forever.
why can't you rerun tests after rebase to run tests if the patch is critical and pending?
----- Original Message -----
From: "David Caro" <dcaroest@redhat.com> To: devel@ovirt.org, infra@ovirt.org Sent: Tuesday, December 9, 2014 11:43:04 AM Subject: [ovirt-devel] Creating a new gerrit flag
Hi!
e have been having an issue with gerrit patches being merged before jenkins ran any tests on them, to avoid it from happening again I propose creating a new gerrit flag (Tests) with the following specifics:
+1 - Tests passed/overrided 0 - Tests pending -1 - Tests broken
where +1 is required to submit, +1 is set by jenkins when passing the tests and -1 is set by jenkins in case it breaks any tests. The +1 flag can be set also by maintainers to allow overriding the process.
That way all the tests will be blocked until someone (hopefully jenkins) adds the +1 flag, but if the maintainer wants to override the value, she just has to set that flag herself.
What do you think?
-- 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
_______________________________________________ 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
----- Original Message -----
From: "Yaniv Dary" <ydary@redhat.com> To: "Oved Ourfali" <ovedo@redhat.com> Cc: devel@ovirt.org, infra@ovirt.org Sent: Tuesday, December 9, 2014 12:10:36 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag
----- Original Message -----
From: "Oved Ourfali" <ovedo@redhat.com> To: "David Caro" <dcaroest@redhat.com> Cc: infra@ovirt.org, devel@ovirt.org Sent: Tuesday, December 9, 2014 11:52:11 AM Subject: Re: [ovirt-devel] Creating a new gerrit flag
What happens when rebasing? We can't afford waiting for tests to run on each rebase... as we might end up rebasing forever.
why can't you rerun tests after rebase to run tests if the patch is critical and pending?
I meant manually.
----- Original Message -----
From: "David Caro" <dcaroest@redhat.com> To: devel@ovirt.org, infra@ovirt.org Sent: Tuesday, December 9, 2014 11:43:04 AM Subject: [ovirt-devel] Creating a new gerrit flag
Hi!
e have been having an issue with gerrit patches being merged before jenkins ran any tests on them, to avoid it from happening again I propose creating a new gerrit flag (Tests) with the following specifics:
+1 - Tests passed/overrided 0 - Tests pending -1 - Tests broken
where +1 is required to submit, +1 is set by jenkins when passing the tests and -1 is set by jenkins in case it breaks any tests. The +1 flag can be set also by maintainers to allow overriding the process.
That way all the tests will be blocked until someone (hopefully jenkins) adds the +1 flag, but if the maintainer wants to override the value, she just has to set that flag herself.
What do you think?
-- 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
_______________________________________________ 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
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
----- Original Message -----
From: "Yaniv Dary" <ydary@redhat.com> To: "Oved Ourfali" <ovedo@redhat.com> Cc: infra@ovirt.org, devel@ovirt.org Sent: Tuesday, December 9, 2014 12:11:31 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag
----- Original Message -----
From: "Yaniv Dary" <ydary@redhat.com> To: "Oved Ourfali" <ovedo@redhat.com> Cc: devel@ovirt.org, infra@ovirt.org Sent: Tuesday, December 9, 2014 12:10:36 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag
----- Original Message -----
From: "Oved Ourfali" <ovedo@redhat.com> To: "David Caro" <dcaroest@redhat.com> Cc: infra@ovirt.org, devel@ovirt.org Sent: Tuesday, December 9, 2014 11:52:11 AM Subject: Re: [ovirt-devel] Creating a new gerrit flag
What happens when rebasing? We can't afford waiting for tests to run on each rebase... as we might end up rebasing forever.
why can't you rerun tests after rebase to run tests if the patch is critical and pending?
I meant manually.
You can run. The issue is that while running them, someone else can merge something, and then you'll need to rebase again... and again... and again...
----- Original Message -----
From: "David Caro" <dcaroest@redhat.com> To: devel@ovirt.org, infra@ovirt.org Sent: Tuesday, December 9, 2014 11:43:04 AM Subject: [ovirt-devel] Creating a new gerrit flag
Hi!
e have been having an issue with gerrit patches being merged before jenkins ran any tests on them, to avoid it from happening again I propose creating a new gerrit flag (Tests) with the following specifics:
+1 - Tests passed/overrided 0 - Tests pending -1 - Tests broken
where +1 is required to submit, +1 is set by jenkins when passing the tests and -1 is set by jenkins in case it breaks any tests. The +1 flag can be set also by maintainers to allow overriding the process.
That way all the tests will be blocked until someone (hopefully jenkins) adds the +1 flag, but if the maintainer wants to override the value, she just has to set that flag herself.
What do you think?
-- 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
_______________________________________________ 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
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
--6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 12/09, Oved Ourfali wrote:
What happens when rebasing? We can't afford waiting for tests to run on each rebase... as we might en= d up rebasing forever.
For now we will have to, all the code that is going to be merged must be tested as it is going to be merged, that means running the tests in the last rebase too. In the future there are plans on using a gating system like zuul, so zuul will be the one monitoring the tests and merging when passes, so you will just add the flag, and that will trigger the gate, that runs the tests and merged the patch. It's unlikely that you'll have to wait forever, but there's nothing avoiding you doing that (right now even). I'd like to put emphasis again on differentiating between tests that are fast, that should run on each patch and tests that are slow, that should run on each merge. That will improve the feedback times.
=20 ----- Original Message -----
From: "David Caro" <dcaroest@redhat.com> To: devel@ovirt.org, infra@ovirt.org Sent: Tuesday, December 9, 2014 11:43:04 AM Subject: [ovirt-devel] Creating a new gerrit flag =20 Hi! =20 e have been having an issue with gerrit patches being merged before jenkins ran any tests on them, to avoid it from happening again I propose creating a new gerrit flag (Tests) with the following specifics: =20 =20 +1 - Tests passed/overrided 0 - Tests pending -1 - Tests broken =20 where +1 is required to submit, +1 is set by jenkins when passing the tests and -1 is set by jenkins in case it breaks any tests. The +1 flag can be set also by maintainers to allow overriding the process. =20 That way all the tests will be blocked until someone (hopefully jenkins) adds the +1 flag, but if the maintainer wants to override the value, she just has to set that flag herself. =20 =20 What do you think? =20 =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 _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
--=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 --6c2NcOVqGQ03X4Wi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUhssDAAoJEEBxx+HSYmnDlmAH/jTGLANAfsNTi8QkXiDHONor Ye6SDEmj4Wz77VvFEskba9GDvCjKYUs9yf1dCI+ETba4+ilvlu+M9foEe4x0bpK+ EeVrKUxHyAP+y0hKvUoK1IsNBboJtYLOQcnAjPKnTzgemzvNjhzG+GvUJCVbrmn0 o7Jd1WEE3uCnjEgOnP5V1M+7cP/w0w6pSNhoT0taAU+T3ftXLKBZWZHU5k/hLGwc qSzUYWJlYeW9JYDa4Z0vsaxFUHuppYzpZI37oo7AR6ZoBobs/P+Se7fXUPfscEX3 5cCsM6De/1qZkdfB53b93LYn7VKxGwFAtULFunw5tWshlNb0wtBrupFnkaxmHuA= =BxeC -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi--
----- Original Message -----
From: "David Caro" <dcaroest@redhat.com> To: "Oved Ourfali" <ovedo@redhat.com> Cc: infra@ovirt.org, devel@ovirt.org Sent: Tuesday, December 9, 2014 12:12:19 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag
On 12/09, Oved Ourfali wrote:
What happens when rebasing? We can't afford waiting for tests to run on each rebase... as we might end up rebasing forever.
For now we will have to, all the code that is going to be merged must be tested as it is going to be merged, that means running the tests in the last rebase too.
In the future there are plans on using a gating system like zuul, so zuul will be the one monitoring the tests and merging when passes, so you will just add the flag, and that will trigger the gate, that runs the tests and merged the patch.
It's unlikely that you'll have to wait forever, but there's nothing avoiding you doing that (right now even).
I'd like to put emphasis again on differentiating between tests that are fast, that should run on each patch and tests that are slow, that should run on each merge. That will improve the feedback times.
+1 Tests are more critical than fast merges, the consequences of merging untest patches is worse.
----- Original Message -----
From: "David Caro" <dcaroest@redhat.com> To: devel@ovirt.org, infra@ovirt.org Sent: Tuesday, December 9, 2014 11:43:04 AM Subject: [ovirt-devel] Creating a new gerrit flag
Hi!
e have been having an issue with gerrit patches being merged before jenkins ran any tests on them, to avoid it from happening again I propose creating a new gerrit flag (Tests) with the following specifics:
+1 - Tests passed/overrided 0 - Tests pending -1 - Tests broken
where +1 is required to submit, +1 is set by jenkins when passing the tests and -1 is set by jenkins in case it breaks any tests. The +1 flag can be set also by maintainers to allow overriding the process.
That way all the tests will be blocked until someone (hopefully jenkins) adds the +1 flag, but if the maintainer wants to override the value, she just has to set that flag herself.
What do you think?
-- 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
_______________________________________________ Devel mailing list Devel@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@redhat.com Web: www.redhat.com RHT Global #: 82-62605
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
----- Original Message -----
From: "David Caro" <dcaroest@redhat.com> To: "Oved Ourfali" <ovedo@redhat.com> Cc: infra@ovirt.org, devel@ovirt.org Sent: Tuesday, December 9, 2014 12:12:19 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag
On 12/09, Oved Ourfali wrote:
What happens when rebasing? We can't afford waiting for tests to run on each rebase... as we might end up rebasing forever.
For now we will have to, all the code that is going to be merged must be tested as it is going to be merged, that means running the tests in the last rebase too.
In the future there are plans on using a gating system like zuul, so zuul will be the one monitoring the tests and merging when passes, so you will just add the flag, and that will trigger the gate, that runs the tests and merged the patch.
It's unlikely that you'll have to wait forever, but there's nothing avoiding you doing that (right now even).
I'd like to put emphasis again on differentiating between tests that are fast, that should run on each patch and tests that are slow, that should run on each merge. That will improve the feedback times.
So let's apply that in the future. For now the amount of merges done is enormous, and it will be impossible to get things merged on a reasonable time. Again, I'm not against testing, but it should be done the right way...
----- Original Message -----
From: "David Caro" <dcaroest@redhat.com> To: devel@ovirt.org, infra@ovirt.org Sent: Tuesday, December 9, 2014 11:43:04 AM Subject: [ovirt-devel] Creating a new gerrit flag
Hi!
e have been having an issue with gerrit patches being merged before jenkins ran any tests on them, to avoid it from happening again I propose creating a new gerrit flag (Tests) with the following specifics:
+1 - Tests passed/overrided 0 - Tests pending -1 - Tests broken
where +1 is required to submit, +1 is set by jenkins when passing the tests and -1 is set by jenkins in case it breaks any tests. The +1 flag can be set also by maintainers to allow overriding the process.
That way all the tests will be blocked until someone (hopefully jenkins) adds the +1 flag, but if the maintainer wants to override the value, she just has to set that flag herself.
What do you think?
-- 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
_______________________________________________ Devel mailing list Devel@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@redhat.com Web: www.redhat.com RHT Global #: 82-62605
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
top posting: How about the following flow: 1. You push a patch to gerrit. 2. You need +1 on Testing in order to merge it. 3. You have +1/-1 on the Tests if finished successfully/failed 4. You find out you need to rebase. 5. The rebase copies the result of the Tests of the previous patch-set... if it was +1, it remains +1 and you can merge (assuming you have +2 on CR). If it was -1 then you need to wait for the CI to finish, and it might set it to +1. Does that make sense? ----- Original Message -----
From: "Oved Ourfali" <ovedo@redhat.com> To: "David Caro" <dcaroest@redhat.com> Cc: devel@ovirt.org, infra@ovirt.org Sent: Tuesday, December 9, 2014 1:13:57 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag
----- Original Message -----
From: "David Caro" <dcaroest@redhat.com> To: "Oved Ourfali" <ovedo@redhat.com> Cc: infra@ovirt.org, devel@ovirt.org Sent: Tuesday, December 9, 2014 12:12:19 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag
On 12/09, Oved Ourfali wrote:
What happens when rebasing? We can't afford waiting for tests to run on each rebase... as we might end up rebasing forever.
For now we will have to, all the code that is going to be merged must be tested as it is going to be merged, that means running the tests in the last rebase too.
In the future there are plans on using a gating system like zuul, so zuul will be the one monitoring the tests and merging when passes, so you will just add the flag, and that will trigger the gate, that runs the tests and merged the patch.
It's unlikely that you'll have to wait forever, but there's nothing avoiding you doing that (right now even).
I'd like to put emphasis again on differentiating between tests that are fast, that should run on each patch and tests that are slow, that should run on each merge. That will improve the feedback times.
So let's apply that in the future. For now the amount of merges done is enormous, and it will be impossible to get things merged on a reasonable time. Again, I'm not against testing, but it should be done the right way...
----- Original Message -----
From: "David Caro" <dcaroest@redhat.com> To: devel@ovirt.org, infra@ovirt.org Sent: Tuesday, December 9, 2014 11:43:04 AM Subject: [ovirt-devel] Creating a new gerrit flag
Hi!
e have been having an issue with gerrit patches being merged before jenkins ran any tests on them, to avoid it from happening again I propose creating a new gerrit flag (Tests) with the following specifics:
+1 - Tests passed/overrided 0 - Tests pending -1 - Tests broken
where +1 is required to submit, +1 is set by jenkins when passing the tests and -1 is set by jenkins in case it breaks any tests. The +1 flag can be set also by maintainers to allow overriding the process.
That way all the tests will be blocked until someone (hopefully jenkins) adds the +1 flag, but if the maintainer wants to override the value, she just has to set that flag herself.
What do you think?
-- 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
_______________________________________________ Devel mailing list Devel@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@redhat.com Web: www.redhat.com RHT Global #: 82-62605
_______________________________________________ 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
----- Original Message -----
From: "Oved Ourfali" <ovedo@redhat.com> To: "David Caro" <dcaroest@redhat.com> Cc: infra@ovirt.org, devel@ovirt.org Sent: Tuesday, December 9, 2014 2:27:14 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag
top posting: How about the following flow: 1. You push a patch to gerrit. 2. You need +1 on Testing in order to merge it. 3. You have +1/-1 on the Tests if finished successfully/failed 4. You find out you need to rebase. 5. The rebase copies the result of the Tests of the previous patch-set... if it was +1, it remains +1 and you can merge (assuming you have +2 on CR). If it was -1 then you need to wait for the CI to finish, and it might set it to +1.
Does that make sense?
Yes, but only if you used rebase button and automatic rebase worked. In case of merge conflict you will need to wait after rebase for tests.
----- Original Message -----
From: "Oved Ourfali" <ovedo@redhat.com> To: "David Caro" <dcaroest@redhat.com> Cc: devel@ovirt.org, infra@ovirt.org Sent: Tuesday, December 9, 2014 1:13:57 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag
----- Original Message -----
From: "David Caro" <dcaroest@redhat.com> To: "Oved Ourfali" <ovedo@redhat.com> Cc: infra@ovirt.org, devel@ovirt.org Sent: Tuesday, December 9, 2014 12:12:19 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag
On 12/09, Oved Ourfali wrote:
What happens when rebasing? We can't afford waiting for tests to run on each rebase... as we might end up rebasing forever.
For now we will have to, all the code that is going to be merged must be tested as it is going to be merged, that means running the tests in the last rebase too.
In the future there are plans on using a gating system like zuul, so zuul will be the one monitoring the tests and merging when passes, so you will just add the flag, and that will trigger the gate, that runs the tests and merged the patch.
It's unlikely that you'll have to wait forever, but there's nothing avoiding you doing that (right now even).
I'd like to put emphasis again on differentiating between tests that are fast, that should run on each patch and tests that are slow, that should run on each merge. That will improve the feedback times.
So let's apply that in the future. For now the amount of merges done is enormous, and it will be impossible to get things merged on a reasonable time. Again, I'm not against testing, but it should be done the right way...
----- Original Message -----
From: "David Caro" <dcaroest@redhat.com> To: devel@ovirt.org, infra@ovirt.org Sent: Tuesday, December 9, 2014 11:43:04 AM Subject: [ovirt-devel] Creating a new gerrit flag
Hi!
e have been having an issue with gerrit patches being merged before jenkins ran any tests on them, to avoid it from happening again I propose creating a new gerrit flag (Tests) with the following specifics:
+1 - Tests passed/overrided 0 - Tests pending -1 - Tests broken
where +1 is required to submit, +1 is set by jenkins when passing the tests and -1 is set by jenkins in case it breaks any tests. The +1 flag can be set also by maintainers to allow overriding the process.
That way all the tests will be blocked until someone (hopefully jenkins) adds the +1 flag, but if the maintainer wants to override the value, she just has to set that flag herself.
What do you think?
-- 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
_______________________________________________ Devel mailing list Devel@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@redhat.com Web: www.redhat.com RHT Global #: 82-62605
_______________________________________________ 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
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
----- Original Message -----
From: "Yaniv Dary" <ydary@redhat.com> To: "Oved Ourfali" <ovedo@redhat.com> Cc: devel@ovirt.org, infra@ovirt.org Sent: Tuesday, December 9, 2014 2:29:38 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag
----- Original Message -----
From: "Oved Ourfali" <ovedo@redhat.com> To: "David Caro" <dcaroest@redhat.com> Cc: infra@ovirt.org, devel@ovirt.org Sent: Tuesday, December 9, 2014 2:27:14 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag
top posting: How about the following flow: 1. You push a patch to gerrit. 2. You need +1 on Testing in order to merge it. 3. You have +1/-1 on the Tests if finished successfully/failed 4. You find out you need to rebase. 5. The rebase copies the result of the Tests of the previous patch-set... if it was +1, it remains +1 and you can merge (assuming you have +2 on CR). If it was -1 then you need to wait for the CI to finish, and it might set it to +1.
Does that make sense?
Yes, but only if you used rebase button and automatic rebase worked. In case of merge conflict you will need to wait after rebase for tests.
In such cases I think the reviewer should compare and decide, rather than wait for tests to finish.
----- Original Message -----
From: "Oved Ourfali" <ovedo@redhat.com> To: "David Caro" <dcaroest@redhat.com> Cc: devel@ovirt.org, infra@ovirt.org Sent: Tuesday, December 9, 2014 1:13:57 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag
----- Original Message -----
From: "David Caro" <dcaroest@redhat.com> To: "Oved Ourfali" <ovedo@redhat.com> Cc: infra@ovirt.org, devel@ovirt.org Sent: Tuesday, December 9, 2014 12:12:19 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag
On 12/09, Oved Ourfali wrote:
What happens when rebasing? We can't afford waiting for tests to run on each rebase... as we might end up rebasing forever.
For now we will have to, all the code that is going to be merged must be tested as it is going to be merged, that means running the tests in the last rebase too.
In the future there are plans on using a gating system like zuul, so zuul will be the one monitoring the tests and merging when passes, so you will just add the flag, and that will trigger the gate, that runs the tests and merged the patch.
It's unlikely that you'll have to wait forever, but there's nothing avoiding you doing that (right now even).
I'd like to put emphasis again on differentiating between tests that are fast, that should run on each patch and tests that are slow, that should run on each merge. That will improve the feedback times.
So let's apply that in the future. For now the amount of merges done is enormous, and it will be impossible to get things merged on a reasonable time. Again, I'm not against testing, but it should be done the right way...
----- Original Message -----
From: "David Caro" <dcaroest@redhat.com> To: devel@ovirt.org, infra@ovirt.org Sent: Tuesday, December 9, 2014 11:43:04 AM Subject: [ovirt-devel] Creating a new gerrit flag
Hi!
e have been having an issue with gerrit patches being merged before jenkins ran any tests on them, to avoid it from happening again I propose creating a new gerrit flag (Tests) with the following specifics:
+1 - Tests passed/overrided 0 - Tests pending -1 - Tests broken
where +1 is required to submit, +1 is set by jenkins when passing the tests and -1 is set by jenkins in case it breaks any tests. The +1 flag can be set also by maintainers to allow overriding the process.
That way all the tests will be blocked until someone (hopefully jenkins) adds the +1 flag, but if the maintainer wants to override the value, she just has to set that flag herself.
What do you think?
-- 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
_______________________________________________ Devel mailing list Devel@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@redhat.com Web: www.redhat.com RHT Global #: 82-62605
_______________________________________________ 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
_______________________________________________ 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
--H8ygTp4AXg6deix2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 12/09, Yaniv Dary wrote:
=20 =20 ----- Original Message -----
From: "Oved Ourfali" <ovedo@redhat.com> To: "David Caro" <dcaroest@redhat.com> Cc: infra@ovirt.org, devel@ovirt.org Sent: Tuesday, December 9, 2014 2:27:14 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag =20 top posting: How about the following flow: 1. You push a patch to gerrit. 2. You need +1 on Testing in order to merge it. 3. You have +1/-1 on the Tests if finished successfully/failed 4. You find out you need to rebase. 5. The rebase copies the result of the Tests of the previous patch-set.= =2E. if it was +1, it remains +1 and you can merge (assuming you have +2 on CR)= =2E If it was -1 then you need to wait for the CI to finish, and it might set = it to +1. =20 Does that make sense? =20 Yes, but only if you used rebase button and automatic rebase worked. In case of merge conflict you will need to wait after rebase for tests.
Well, that's more or less what's happening today, we did set up the flag propagation on trivial rebase time ago. I'll have to check how to make jenkins ignore those trivial rebases only if they have a +1. So are you sure that having no merge conflict means that the rebase patch works as before? (I imagine for example that you could have two features that together might not work well, even if they do not touch the same code)
=20
=20 ----- Original Message -----
From: "Oved Ourfali" <ovedo@redhat.com> To: "David Caro" <dcaroest@redhat.com> Cc: devel@ovirt.org, infra@ovirt.org Sent: Tuesday, December 9, 2014 1:13:57 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag =20 =20 =20 ----- Original Message -----
What happens when rebasing? We can't afford waiting for tests to run on each rebase... as we = might end up rebasing forever. =20 For now we will have to, all the code that is going to be merged mu= st be tested as it is going to be merged, that means running the tests= in
From: "David Caro" <dcaroest@redhat.com> To: "Oved Ourfali" <ovedo@redhat.com> Cc: infra@ovirt.org, devel@ovirt.org Sent: Tuesday, December 9, 2014 12:12:19 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag =20 On 12/09, Oved Ourfali wrote: the last rebase too. =20 In the future there are plans on using a gating system like zuul, so zuul will be the one monitoring the tests and merging when passes, = so you will just add the flag, and that will trigger the gate, that ru= ns the tests and merged the patch. =20 It's unlikely that you'll have to wait forever, but there's nothing avoiding you doing that (right now even). =20 I'd like to put emphasis again on differentiating between tests that are fast, that should run on each patch and tests that are slow, th= at should run on each merge. That will improve the feedback times. =20 =20 So let's apply that in the future. For now the amount of merges done is enormous, and it will be impossi= ble to get things merged on a reasonable time. Again, I'm not against testing, but it should be done the right way... =20
=20 ----- Original Message -----
From: "David Caro" <dcaroest@redhat.com> To: devel@ovirt.org, infra@ovirt.org Sent: Tuesday, December 9, 2014 11:43:04 AM Subject: [ovirt-devel] Creating a new gerrit flag =20 Hi! =20 e have been having an issue with gerrit patches being merged be= fore jenkins ran any tests on them, to avoid it from happening again= I propose creating a new gerrit flag (Tests) with the following specifics: =20 =20 +1 - Tests passed/overrided 0 - Tests pending -1 - Tests broken =20 where +1 is required to submit, +1 is set by jenkins when passing the tests and -1 is set by jenkins in case it breaks any tests. The +1 flag can be set also by maintainers to allow over= riding the process. =20 That way all the tests will be blocked until someone (hopefully jenkins) adds the +1 flag, but if the maintainer wants to overr= ide the value, she just has to set that flag herself. =20 =20 What do you think? =20 =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 _______________________________________________ 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
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
Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel =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 --H8ygTp4AXg6deix2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUhu3LAAoJEEBxx+HSYmnDdP0H/3RLp7CSIAP9HgffU/hBC/G2 wEZzBNIgaeeZ4wkjaPjN8tijl7iXX+/1f3CsIZNfrCEkl5b+gd9MZYsoczPGuXxX p8VuYM0Z/MgBNrz6b8p72wAGD3NuaK/UDnlbE7hsaYVb72t2SBBpYbFAvi6h/OWf GfteLxFI6NH3EF6j0u08wE2msM4270G6dh9D6h3nvUzyYAoNUaGFpZKlGGuKV9XC tcuH+i+GGyzg6QF8jBVgLDYKLi2ZYMhfKJpzTNXI8gkcAJp6HRgVi3TrIS5xNpp2 +f688J+oH4c+EZgV/DPu93r4f+OzHnhfK0BNjGX4G0HqYx8la4QN+f2GyaPdgKs= =Oqyk -----END PGP SIGNATURE----- --H8ygTp4AXg6deix2--
----- Original Message -----
From: "David Caro" <dcaroest@redhat.com> To: "Yaniv Dary" <ydary@redhat.com> Cc: "Oved Ourfali" <ovedo@redhat.com>, devel@ovirt.org, infra@ovirt.org Sent: Tuesday, December 9, 2014 2:40:43 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag
On 12/09, Yaniv Dary wrote:
----- Original Message -----
From: "Oved Ourfali" <ovedo@redhat.com> To: "David Caro" <dcaroest@redhat.com> Cc: infra@ovirt.org, devel@ovirt.org Sent: Tuesday, December 9, 2014 2:27:14 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag
top posting: How about the following flow: 1. You push a patch to gerrit. 2. You need +1 on Testing in order to merge it. 3. You have +1/-1 on the Tests if finished successfully/failed 4. You find out you need to rebase. 5. The rebase copies the result of the Tests of the previous patch-set... if it was +1, it remains +1 and you can merge (assuming you have +2 on CR). If it was -1 then you need to wait for the CI to finish, and it might set it to +1.
Does that make sense?
Yes, but only if you used rebase button and automatic rebase worked. In case of merge conflict you will need to wait after rebase for tests.
Well, that's more or less what's happening today, we did set up the flag propagation on trivial rebase time ago. I'll have to check how to make jenkins ignore those trivial rebases only if they have a +1.
So are you sure that having no merge conflict means that the rebase patch works as before? (I imagine for example that you could have two features that together might not work well, even if they do not touch the same code)
You minimize the probability that something will get wrong. It isn't 100%. Using Zuul is the right way to go, but until you have that I think what I proposed will make it both easy to use and maintain, and both safe up to 95% or so.
----- Original Message -----
From: "Oved Ourfali" <ovedo@redhat.com> To: "David Caro" <dcaroest@redhat.com> Cc: devel@ovirt.org, infra@ovirt.org Sent: Tuesday, December 9, 2014 1:13:57 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag
----- Original Message -----
From: "David Caro" <dcaroest@redhat.com> To: "Oved Ourfali" <ovedo@redhat.com> Cc: infra@ovirt.org, devel@ovirt.org Sent: Tuesday, December 9, 2014 12:12:19 PM Subject: Re: [ovirt-devel] Creating a new gerrit flag
On 12/09, Oved Ourfali wrote:
What happens when rebasing? We can't afford waiting for tests to run on each rebase... as we might end up rebasing forever.
For now we will have to, all the code that is going to be merged must be tested as it is going to be merged, that means running the tests in the last rebase too.
In the future there are plans on using a gating system like zuul, so zuul will be the one monitoring the tests and merging when passes, so you will just add the flag, and that will trigger the gate, that runs the tests and merged the patch.
It's unlikely that you'll have to wait forever, but there's nothing avoiding you doing that (right now even).
I'd like to put emphasis again on differentiating between tests that are fast, that should run on each patch and tests that are slow, that should run on each merge. That will improve the feedback times.
So let's apply that in the future. For now the amount of merges done is enormous, and it will be impossible to get things merged on a reasonable time. Again, I'm not against testing, but it should be done the right way...
----- Original Message ----- > From: "David Caro" <dcaroest@redhat.com> > To: devel@ovirt.org, infra@ovirt.org > Sent: Tuesday, December 9, 2014 11:43:04 AM > Subject: [ovirt-devel] Creating a new gerrit flag > > Hi! > > e have been having an issue with gerrit patches being merged > before > jenkins ran any tests on them, to avoid it from happening again I > propose creating a new gerrit flag (Tests) with the following > specifics: > > > +1 - Tests passed/overrided > 0 - Tests pending > -1 - Tests broken > > where +1 is required to submit, +1 is set by jenkins when > passing the tests and -1 is set by jenkins in case it breaks any > tests. The +1 flag can be set also by maintainers to allow > overriding > the process. > > That way all the tests will be blocked until someone (hopefully > jenkins) adds the +1 flag, but if the maintainer wants to > override > the > value, she just has to set that flag herself. > > > What do you think? > > > -- > 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 > > _______________________________________________ > Devel mailing list > Devel@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@redhat.com Web: www.redhat.com RHT Global #: 82-62605
_______________________________________________ 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
_______________________________________________ Devel mailing list Devel@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@redhat.com Web: www.redhat.com RHT Global #: 82-62605
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
participants (4)
-
David Caro -
Francesco Romani -
Oved Ourfali -
Yaniv Dary