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" <ov...@redhat.com> > To: "David Caro" <dcaro...@redhat.com> > Cc: devel@ovirt.org, in...@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" <dcaro...@redhat.com> > > To: "Oved Ourfali" <ov...@redhat.com> > > Cc: in...@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" <dcaro...@redhat.com> > > > > To: devel@ovirt.org, in...@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: dc...@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: dc...@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
