2:40 a.m.
----- Original Message -----
From: "Oved Ourfali" <ovedo(a)redhat.com>
To: "David Caro" <dcaroest(a)redhat.com>
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>
> To: "Oved Ourfali" <ovedo(a)redhat.com>
> 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>
> > > To: "Oved Ourfali" <ovedo(a)redhat.com>
> > > Cc: "Sven Kieske" <s.kieske(a)mittwald.de>, 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>
> > > > > 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
>
+1, we need a way to block bad patches from being merged, even with a rebase in gerrit.
going forward we're planning a few changes to the way jenkins jobs are run on ovirt
ci, which will help
reduce noise and imrove resources usages.
1. moving into a flow process, where critical jobs like unit tests/checkstyle will run
first and only then other heavy jobs will run (integration/rpms/findbugs)
2. using gating system like zuul to do the merge after verification of sanity jobs
automatically.
these will take time of course and will be done gradually.
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