=20 =20 On 25 Mar 2015, at 13:58, David Caro <dcaroest@redhat.com> wrote: =20
=20 This was done because it was requested some time ago. =20 That will also remind devels that they should not merge any patches tha= t have not finished running the jenkins jobs yet. =20 In a (hopefully) near future, that will not be needed as jobs will beco= me a gateway to merge, meaning that the regular merge flow will require pass= ing the jenkins jobs. =20 I would strongly object to this, until we have a positive experience of n= o false positives for at least couple of months. Then it is a great idea.=20 =20 That's like expecting that every patch sent for review to pass all the test= s, all the time for a month and not failing once, and I don't mean each MERGED
--+9uAEI//NVSmpZEF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 03/26, Michal Skrivanek wrote: patch, I mean each one sent for review. Just so you have some numbers on what you are currently asking for, some st= ats about builds for the last two weeks: Number of SUCCESS builds: 50061 Number of FAILED builds: 1777 Number of UNSTABLE builds: 749 Number of ABORTED builds: 124 Number of NOTBUILT builds: 326 Total number of builds: 53037 Percentage of failed builds: 5.61% Here, failed builds includes infra issues and test failures, we don't have means yet to properly distinguish both. I know this is including all the projects, not just the most 'complicated' ones, but that means that, on small projects, where the maintainer of the project is also writing it's own acceptance tests, the failure ratio is a l= ot lower than on the bigger projects, where the failures are ignored and the t= ests not maintained, or left for the lonely infra guy that has ~50% of it's time= to handle them all, doing a quick ugly calculation, that guy has 48 seconds to review each failure and fix it (being it an infra issue or not). So you expect that someone that has no involvement on the development of mo= st of the projects, single-handedly fix and triage all those builds, 48 seconds each, and also care about all the other infra-related duties. And not only succeed doing that, but maintain all the system from failing once during two months. I'm sorry but as I see it a lot has to change for that to be feasible, and I really don't think it's fair to request it to that 1/2 guy.
=20
In the meantime, it's just a remainder. =20 On 03/25, Martin Perina wrote:
From: "Greg Sheremeta" <gshereme@redhat.com> To: infra@ovirt.org, "Eyal Edri" <eedri@redhat.com>, "David Caro" <dc= aroest@redhat.com> Cc: devel@ovirt.org Sent: Wednesday, March 25, 2015 1:40:35 PM Subject: [ovirt-devel] gerrit jenkins bot has gotten noisier =20 Hey guys, =20 Sometime last week, the jenkins bot upped the verbosity of his notifications on patches. Was this by design? =20 Example: https://gerrit.ovirt.org/#/c/39098/ =20 He now adds many "build started" messages. He used to only let us know about success / failure. =20 Not a huge deal, but it's more noise to filter through -- both in gerrit and email. =20 Agreed, especially for emails. Personally I don't care about build
=20 =20 ----- Original Message ----- process details, I'd like to know only final result of the build. If the build failed, I could find details on jenkins. =20 Martin =20
=20 Thanks, Greg =20 Greg Sheremeta Red Hat, Inc. Sr. Software Engineer, RHEV Cell: 919-807-1086 gshereme@redhat.com _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel =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
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 --+9uAEI//NVSmpZEF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEbBAEBAgAGBQJVE9eDAAoJEEBxx+HSYmnD/vsH91dhVr+o3T/wIgABxXhkTu1c DqTzR/qnMe4pddgvj82TiVc7pFc3FbnWZFkreetpkkXAGhxI8NdNDTsRNc7GPcnI qc+iIw3qpOz95fdJtjcRsYe/d2l8DdZNxKWHeubetkEDDc8+MYOhrtRlSQQxfP2f zVZPQL4ONphqove57TlyQQHDNJVuNnKHf+mR7lG0LIjhI9/3eHispQJPWhpRA4vj FF1BswMpfR5arOGB62iCqsP6Pamt7cRoONkDx4abaDi8aPAQd5C8M47xZeoSAMkk Kxaj9R5E/GIplXV1IboSA0mxFsJJEodEdkeDDxZBk5Ne7rBAYgNpXIT8kh1bLQ== =PP0i -----END PGP SIGNATURE----- --+9uAEI//NVSmpZEF--