6:27 a.m.
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(a)redhat.com>
To: "David Caro" <dcaroest(a)redhat.com>
Cc: devel(a)ovirt.org, infra(a)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(a)redhat.com>
> To: "Oved Ourfali" <ovedo(a)redhat.com>
> Cc: infra(a)ovirt.org, devel(a)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(a)redhat.com>
> > > To: devel(a)ovirt.org, infra(a)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(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
>
> --
> 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