[ovirt-devel] Creating a new gerrit flag

Oved Ourfali ovedo at redhat.com
Tue Dec 9 12:47:37 UTC 2014 


----- Original Message -----
> From: "David Caro" <dcaroest at redhat.com>
> To: "Yaniv Dary" <ydary at redhat.com>
> Cc: "Oved Ourfali" <ovedo at redhat.com>, devel at ovirt.org, infra at 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 at redhat.com>
> > > To: "David Caro" <dcaroest at redhat.com>
> > > Cc: infra at ovirt.org, devel at 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 at redhat.com>
> > > > To: "David Caro" <dcaroest at redhat.com>
> > > > Cc: devel at ovirt.org, infra at 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 at redhat.com>
> > > > > To: "Oved Ourfali" <ovedo at redhat.com>
> > > > > Cc: infra at ovirt.org, devel at 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 at redhat.com>
> > > > > > > To: devel at ovirt.org, infra at 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 at redhat.com
> > > > > > > Web: www.redhat.com
> > > > > > > RHT Global #: 82-62605
> > > > > > > 
> > > > > > > _______________________________________________
> > > > > > > Devel mailing list
> > > > > > > Devel at 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 at redhat.com
> > > > > Web: www.redhat.com
> > > > > RHT Global #: 82-62605
> > > > > 
> > > > > _______________________________________________
> > > > > Devel mailing list
> > > > > Devel at ovirt.org
> > > > > http://lists.ovirt.org/mailman/listinfo/devel
> > > > _______________________________________________
> > > > Devel mailing list
> > > > Devel at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/devel
> > > > 
> > > _______________________________________________
> > > Devel mailing list
> > > Devel at 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 at redhat.com
> Web: www.redhat.com
> RHT Global #: 82-62605
> 
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel

More information about the Devel mailing list