git review -D -r <repo> <branch>

git review -D -r origin master

----- Original Message ----- > From: "Oved Ourfali" <ovedo(a)redhat.com&gt; > To: "Eyal Edri" <eedri(a)redhat.com&gt; > Cc: infra(a)ovirt.org, devel(a)ovirt.org > Sent: Sunday, June 7, 2015 9:55:56 AM > Subject: Re: [ovirt-devel] gerrit+ci improvement proposal > > > > ----- Original Message ----- > > From: "Eyal Edri" <eedri(a)redhat.com&gt; > > To: "Eli Mesika" <emesika(a)redhat.com&gt; > > Cc: "Oved Ourfali" <ovedo(a)redhat.com&gt;, devel(a)ovirt.org, infra(a)ovirt.org > > Sent: Sunday, June 7, 2015 9:52:15 AM > > Subject: Re: [ovirt-devel] gerrit+ci improvement proposal > > > > > > > > ----- Original Message ----- > > > From: "Eli Mesika" <emesika(a)redhat.com&gt; > > > To: "Oved Ourfali" <ovedo(a)redhat.com&gt; > > > Cc: "Eyal Edri" <eedri(a)redhat.com&gt;, infra(a)ovirt.org, devel(a)ovirt.org > > > Sent: Thursday, June 4, 2015 3:49:05 PM > > > Subject: Re: [ovirt-devel] gerrit+ci improvement proposal > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Oved Ourfali" <ovedo(a)redhat.com&gt; > > > > To: "Eyal Edri" <eedri(a)redhat.com&gt; > > > > Cc: devel(a)ovirt.org, infra(a)ovirt.org > > > > Sent: Thursday, June 4, 2015 10:03:02 AM > > > > Subject: Re: [ovirt-devel] gerrit+ci improvement proposal > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Eyal Edri" <eedri(a)redhat.com&gt; > > > > > To: "Sandro Bonazzola" <sbonazzo(a)redhat.com&gt; > > > > > Cc: infra(a)ovirt.org, devel(a)ovirt.org > > > > > Sent: Thursday, June 4, 2015 9:46:40 AM > > > > > Subject: Re: [ovirt-devel] gerrit+ci improvement proposal > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Sandro Bonazzola" <sbonazzo(a)redhat.com&gt; > > > > > > To: "Eyal Edri" <eedri(a)redhat.com&gt;, "Max Kovgan" > > > > > > <mkovgan(a)redhat.com&gt; > > > > > > Cc: devel(a)ovirt.org, infra(a)ovirt.org > > > > > > Sent: Thursday, June 4, 2015 9:11:10 AM > > > > > > Subject: Re: [ovirt-devel] gerrit+ci improvement proposal > > > > > > > > > > > > Il 03/06/2015 21:46, Eyal Edri ha scritto: > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > >> From: "Max Kovgan" <mkovgan(a)redhat.com&gt; > > > > > > >> To: devel(a)ovirt.org > > > > > > >> Cc: infra(a)ovirt.org > > > > > > >> Sent: Wednesday, June 3, 2015 8:22:54 PM > > > > > > >> Subject: [ovirt-devel] gerrit+ci improvement proposal > > > > > > >> > > > > > > >> Hi everyone! > > > > > > >> We really want to have reliable and snappy CI: to allow short > > > > > > >> cycles > > > > > > >> and > > > > > > >> encourage developers to write tests. > > > > > > >> > > > > > > >> # Problem > > > > > > >> > > > > > > >> Many patches are neither ready for review nor for CI upon > > > > > > >> submission, > > > > > > >> which > > > > > > >> is OK. > > > > > > >> But running all the jobs on those patches with limited resources > > > > > > >> results > > > > > > >> in: > > > > > > >> overloaded resources, slow response time, unhappy developers. > > > > > > >> > > > > > > >> # Proposed Solution > > > > > > >> > > > > > > >> To run less jobs we know we don’t need to, thus making more > > > > > > >> resources > > > > > > >> for > > > > > > >> the > > > > > > >> jobs we need to run. > > > > > > >> We have been experimenting to make our CI stabler and quicker to > > > > > > >> respond > > > > > > >> by > > > > > > >> using gerrit flags. This has improved in both directions very > > > > > > >> well > > > > > > >> internally. > > > > > > >> Now it seems a good time to let all the oVirt projects to use > > > > > > >> this. > > > > > > >> This solution indirectly promotes reviews and quick tests - “to > > > > > > >> fail > > > > > > >> early”, > > > > > > >> yet full blown static code analysis and long tests to run “when > > > > > > >> ready”. > > > > > > >> > > > > > > >> # How it works > > > > > > >> > > > > > > >> 2 new gerrit independent flags are added to gerrit. > > > > > > >> > > > > > > >> ## CI flag > > > > > > >> > > > > > > >> Will express patch CI status. Values: > > > > > > >>  * +1 CI passed > > > > > > >>  *  0 CI did not run yet > > > > > > >>  * -1 CI failed > > > > > > >> Permissions for setting: project maintainers (for special cases) > > > > > > >> should > > > > > > >> be > > > > > > >> able to set/override (except Jenkins). > > > > > > >> > > > > > > >> ## Workflow flag > > > > > > >> > > > > > > >> Will express patch “workflow” state. Values: > > > > > > >>  *  0 Work In Progress > > > > > > >>  * +1 Ready For Review > > > > > > >>  * +2 Ready For Merge > > > > > > >> Permissions for setting: Owner can set +1, Project Maintainers > > > > > > >> can > > > > > > >> set > > > > > > >> +2 > > > > > > >> > > > > > > >> ## Review + CI Integration: > > > > > > >> > > > > > > >> Merging [“Submit” button to appear] will require: Review+1, > > > > > > >> CI+1, > > > > > > >> Workflow+2 > > > > > > >> Patch lifecycle now is: > > > > > > >> --------------------------------------------------------------- > > > > > > >> patch state   |owner     |reviewer |maintainer |CI tests |pass > > > > > > >> --------------------------------------------------------------- > > > > > > >> added/updated |-         |-        |-          |quick    |CI+1 > > > > > > >> review        |Workflow+1|Review+1 |-          |heavy |CI+1 > > > > > > >> merge ready   |-         |-        |Workflow+2 |gating   |CI+1 > > > > > > >> merge         |-         |-        |merge      |merge    |CI+1 > > > > > > >> > > > > > > >> Changes from current workflow: > > > > > > >> Owner only adds reviewers, now owner needs to set "Workflow+1" > > > > > > >> for > > > > > > >> the > > > > > > >> patch > > > > > > >> to be reviewed, and heavily auto-tested. > > > > > > >> Maintainer now needs to set "Workflow+2" and wait for "Submit" > > > > > > >> button > > > > > > >> to > > > > > > >> appear after CI has completed running gating tests. > > > > > > >> > > > > > > >> > > > > > > >> Next step will be to automate merge the change after Workflow+2 > > > > > > >> has > > > > > > >> been > > > > > > >> set > > > > > > >> by the Maintainer and gating tests passed. > > > > > > >> > > > > > > >> > > > > > > >> ## Why now? > > > > > > >> > > > > > > >> It is elimination of waste. The sooner - the better. > > > > > > >> The solution has been used for a while and it works. > > > > > > >> Resolving the problem without gerrit involved will lead to > > > > > > >> adding > > > > > > >> unreliable > > > > > > >> code into jobs, and will still be prone to problems: > > > > > > >>   Just recently, 3d ago we’ve tried detecting what to run from > > > > > > >>   jenkins > > > > > > >>   relying only on gerrit comments so that upon Verified+1, we’d > > > > > > >>   run > > > > > > >>   the > > > > > > >>   job. > > > > > > >>   We could not use “Review+1”, because it makes no sense at all, > > > > > > >>   so > > > > > > >>   we > > > > > > >>   left > > > > > > >>   the job to set Verified+1. > > > > > > >>   Meaning - re-trigger itself immediately more than 1 times. > > > > > > >>   > > > > > > >>   Jenkins and its visitors very unhappy, and we had to stop > > > > > > >>   those > > > > > > >>   jobs, > > > > > > >>   clean > > > > > > >>   up the queue, and spam developers. > > > > > > >> > > > > > > >> ## OK OK OK. Now what? > > > > > > >> > > > > > > >> Now we want your comments and opinions before pushing this > > > > > > >> further: > > > > > > >> Please participate in this thread, so we can start trying it > > > > > > >> out. > > > > > > >> Ask, Suggest better ideas, all this is welcome. > > > > > > >> > > > > > > >> > > > > > > >> Best Regards! > > > > > > >> > > > > > > >> > > > > > > >> N.B. > > > > > > >> Of course, this is not written in stone, in case we find a > > > > > > >> better > > > > > > >> approach > > > > > > >> on > > > > > > >> solving those issues, we will change to it. > > > > > > >> And we will keep improving so don't be afraid that it will be > > > > > > >> enforced: > > > > > > >> if > > > > > > >> this does not work out we will discard it. > > > > > > >> > > > > > > >> P.S. > > > > > > >> Kudos to dcaro, most of the work was done by him, and most of > > > > > > >> this > > > > > > >> text > > > > > > >> too. > > > > > > >> > > > > > > > > > > > > > > +1 from me, releasing CI from running non critical and > > > > > > > un-essential > > > > > > > jobs > > > > > > > will not only reduce load from ci, > > > > > > > and shorted response time for developers, it will allow us to add > > > > > > > much > > > > > > > more > > > > > > > powerful tests such as functional & system > > > > > > > tests that actually add hosts and run VMs, improving our ability > > > > > > > to > > > > > > > find > > > > > > > regression much more effectively. > > > > > > > > > > > > > > Another benefit to consider is saving reviewers time. I.e not > > > > > > > only > > > > > > > jenkins > > > > > > > benefits from Worklow+1, but also human reviewers. > > > > > > > Instead of looking at a patch that is too early to be reviewed, > > > > > > > the > > > > > > > author > > > > > > > can set the Workflow+1 when the code is ready to review > > > > > > > (even if he didn't verified it yet), thus saving time to other > > > > > > > reviewers > > > > > > > - > > > > > > > for example people can add an email rule > > > > > > > to alert them only when they are added to patches that have > > > > > > > Workflow+1, > > > > > > > and > > > > > > > not before. > > > > > > > > > > > > For human reviewers I suggest to keep using drafts until the patch > > > > > > is > > > > > > finished. > > > > > > > > > > keep using? how many developers do you know are working with drafts > > > > > until > > > > > their patch is ready? > > > > > i agree if everyone would use drafts load on jenkins was already much > > > > > lower, > > > > > unfortunately its not the case. > > > > > > > > > > > > > IMO we don't need the "workflow" flag. > > > > I'm okay with CI not running on "drafts". And yes... we do use them. > > > > We can try and educate people to use them more where needed. > > > > Drafts should be widely used in first-phase development, and less on > > > > bug-fixes. > > > > > > > > In addition, I think the patch owners shouldn't add reviewers, unless > > > > they > > > > need their input in the stage of the development. > > > > Once they want input, they should add reviewers. > > > > > > > > 1. So, if the patch is draft then no CI runs on it. > > > > 2. Once it turns into non-draft, you can run "light-CI" on it. > > > > 3. Once the patch has at least one +1 from a (human) reviewer, then it > > > > should > > > > run the "heavy" CI. > > > > 4. Once the patch has +1 from heavy CI, and +2 from reviewer > > > > (maintainer), > > > > then it can be merged. > > > > > > > > That's the process we have today, with slight change on when to run the > > > > CI > > > > and what CI to run (no CI on drafts, light CI on non-draft, heavy CI on > > > > +1 > > > > patches). > > > > > > +1 > > > > > > This is he right approach to go (I am also using drafts and if other > > > don't, > > > we can change that....) > > > Also, regarding the claim that publishing a draft is a one-way process, I > > > don't think that this is problematic, you should publish a draft after it > > > is > > > stable and you addressed all comments and run all tests locally > > > > > > > this might be true, but the problem is: > >  1. we can't enforce people to use drafts (technically), so until they do, > >  we'll still have a resource problem > > > We can educate, and I don't see an issue with that. > > >  2. until we do, even "light ci" jobs running per patch will overload the > >  ci > >  without need, this is why relying on another > >     flag will help - if adding workflow is a problem, we can use the CR+1 > >     as > >     first attempt to improve the flow, > >     and consider in the future to use workflow if it will be needed. (maybe > >     we can even set it automatically somehow) > > > > Perhaps marking as "verified" can be this flag. > If the patch is verified by the author, then you run light CI on it. > If it was also CR+1, run the heavy CI. question is how soon does an author ticks verify on his patch? does he wait for code review before? for e.g. - i heard from some developers they wait for CI to give them +1 until they even add reviewers, so this might be the chicken and egg problem.

> > That way you both don't need a new flag, and you don't waste resources on > non-manually-verified bugs. > > > > > > > > > > > > > > > > > > > Once it's finished and humans reviewed the logic of the patch, > > > > > > Workflow+1 > > > > > > should be triggered allowing automation to check the correctness of > > > > > > the > > > > > > patch. > > > > > > IMHO there's no reason for wasting CI time on patches that will be > > > > > > correct > > > > > > from an automation point of view but nacked by reviewers. > > > > > > Especially > > > > > > if > > > > > > the > > > > > > patches are part of a big patchset. > > > > > > > > > > > > > > > > > > > > > > > > > > And one final note, for Workflow+2 -> this is a preparation for a > > > > > > > gating > > > > > > > system, like Zuul used by openstack, that in the future > > > > > > > we might use as automatic merger pending passing a verification > > > > > > > step. > > > > > > > this > > > > > > > will prevent errors that happen sometimes > > > > > > > post merge due to conflicts or other issues, and will be another > > > > > > > level > > > > > > > of > > > > > > > validation before final merge. > > > > > > > But as max said, its all part of the plan and we'll test it of > > > > > > > course > > > > > > > before implementing to see its value. > > > > > > > > > > > > > > > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> Max Kovgan > > > > > > >> > > > > > > >> Senior Software Engineer > > > > > > >> Red Hat - EMEA ENG Virtualization R&D > > > > > > >> Tel.: +972 9769 2060 > > > > > > >> Email: mkovgan [at] redhat [dot] com > > > > > > >> Web: http://www.redhat.com > > > > > > >> RHT Global #: 82-72060 > > > > > > >> > > > > > > >> _______________________________________________ > > > > > > >> 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 > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Sandro Bonazzola > > > > > > Better technology. Faster innovation. Powered by community > > > > > > collaboration. > > > > > > See how it works at redhat.com > > > > > > _______________________________________________ > > > > > > Infra mailing list > > > > > > Infra(a)ovirt.org > > > > > > http://lists.ovirt.org/mailman/listinfo/infra > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Devel mailing list > > > > > Devel(a)ovirt.org > > > > > http://lists.ovirt.org/mailman/listinfo/devel > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Infra mailing list > > > > Infra(a)ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/infra > > > > > > > _______________________________________________ > > > Infra mailing list > > > Infra(a)ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/infra > > > > > > > > > > > _______________________________________________ > > Infra mailing list > > Infra(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > > _______________________________________________ > Infra mailing list > Infra(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra > > > _______________________________________________ Devel mailing list Devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/devel

hi, Dear Developers! We are aware of the urge and pressure to push your patches a.s.a.p before the code freeze. Howeever, with current flow of patch updates, we currently have an overloaded CI, which will result in a very long waiting time for jobs to start SO, in order to reduce that time, please make sure you are using DRAFTs [1] for early stage patches [during human reviews] how to use drafts: 1) using plain git push - refer to [1] 2) using git review plugin if you've installed git review plugin: > git review -D -r <repo> <branch> example with repo "origin" and branch "master": > git review -D -r origin master plugin can be installed as explained here: [2] [1] http://stackoverflow.com/questions/18106064/how-to-push-drafts-to-gerrit [2] http://www.mediawiki.org/wiki/Gerrit/git-review#Fedora.2FCentOS N.B. Using drafts is the only alternative for adding 2 new gerrit flags. If you have better ideas - you are still welcome to suggest. Earlier today I did some mining on gerrit patches status: out of ~1400 open patches ~350 are drafts, which was incouraging. Yet out of all 66 committers for those patches only 6 are using drafts: In [25]: for c in changes: ....: if c.get('status') != 'DRAFT': ....: continue ....: saints.add(c.get('owner').get('name')) ....: In [26]: saints Out[26]: {u'Alon Bar-Lev', u'Liron Aravot', u'Martin Mucha', u'Nir Soffer', u'Piotr Kliczewski', u'Tomer Saban'} Kudos. Max Kovgan Senior Software Engineer Red Hat - EMEA ENG Virtualization R&D Tel.: +972 9769 2060 Email: mkovgan [at] redhat [dot] com Web: http://www.redhat.com RHT Global #: 82-72060 ----- Forwarded Message ----- From: "Oved Ourfali" <oourfali(a)redhat.com&gt; To: "Eyal Edri" <eedri(a)redhat.com&gt; Cc: "Oved Ourfali" <ovedo(a)redhat.com&gt;, devel(a)ovirt.org, "infra" <infra(a)ovirt.org&gt; Sent: Sunday, June 7, 2015 10:05:23 AM Subject: Re: [ovirt-devel] gerrit+ci improvement proposal On Jun 7, 2015 10:00 AM, Eyal Edri <eedri(a)redhat.com&gt; wrote: > > > > ----- Original Message ----- > > From: "Oved Ourfali" <ovedo(a)redhat.com&gt; > > To: "Eyal Edri" <eedri(a)redhat.com&gt; > > Cc: infra(a)ovirt.org, devel(a)ovirt.org > > Sent: Sunday, June 7, 2015 9:55:56 AM > > Subject: Re: [ovirt-devel] gerrit+ci improvement proposal > > > > > > > > ----- Original Message ----- > > > From: "Eyal Edri" <eedri(a)redhat.com&gt; > > > To: "Eli Mesika" <emesika(a)redhat.com&gt; > > > Cc: "Oved Ourfali" <ovedo(a)redhat.com&gt;, devel(a)ovirt.org, infra(a)ovirt.org > > > Sent: Sunday, June 7, 2015 9:52:15 AM > > > Subject: Re: [ovirt-devel] gerrit+ci improvement proposal > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Eli Mesika" <emesika(a)redhat.com&gt; > > > > To: "Oved Ourfali" <ovedo(a)redhat.com&gt; > > > > Cc: "Eyal Edri" <eedri(a)redhat.com&gt;, infra(a)ovirt.org, devel(a)ovirt.org > > > > Sent: Thursday, June 4, 2015 3:49:05 PM > > > > Subject: Re: [ovirt-devel] gerrit+ci improvement proposal > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Oved Ourfali" <ovedo(a)redhat.com&gt; > > > > > To: "Eyal Edri" <eedri(a)redhat.com&gt; > > > > > Cc: devel(a)ovirt.org, infra(a)ovirt.org > > > > > Sent: Thursday, June 4, 2015 10:03:02 AM > > > > > Subject: Re: [ovirt-devel] gerrit+ci improvement proposal > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Eyal Edri" <eedri(a)redhat.com&gt; > > > > > > To: "Sandro Bonazzola" <sbonazzo(a)redhat.com&gt; > > > > > > Cc: infra(a)ovirt.org, devel(a)ovirt.org > > > > > > Sent: Thursday, June 4, 2015 9:46:40 AM > > > > > > Subject: Re: [ovirt-devel] gerrit+ci improvement proposal > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Sandro Bonazzola" <sbonazzo(a)redhat.com&gt; > > > > > > > To: "Eyal Edri" <eedri(a)redhat.com&gt;, "Max Kovgan" > > > > > > > <mkovgan(a)redhat.com&gt; > > > > > > > Cc: devel(a)ovirt.org, infra(a)ovirt.org > > > > > > > Sent: Thursday, June 4, 2015 9:11:10 AM > > > > > > > Subject: Re: [ovirt-devel] gerrit+ci improvement proposal > > > > > > > > > > > > > > Il 03/06/2015 21:46, Eyal Edri ha scritto: > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > >> From: "Max Kovgan" <mkovgan(a)redhat.com&gt; > > > > > > > >> To: devel(a)ovirt.org > > > > > > > >> Cc: infra(a)ovirt.org > > > > > > > >> Sent: Wednesday, June 3, 2015 8:22:54 PM > > > > > > > >> Subject: [ovirt-devel] gerrit+ci improvement proposal > > > > > > > >> > > > > > > > >> Hi everyone! > > > > > > > >> We really want to have reliable and snappy CI: to allow short > > > > > > > >> cycles > > > > > > > >> and > > > > > > > >> encourage developers to write tests. > > > > > > > >> > > > > > > > >> # Problem > > > > > > > >> > > > > > > > >> Many patches are neither ready for review nor for CI upon > > > > > > > >> submission, > > > > > > > >> which > > > > > > > >> is OK. > > > > > > > >> But running all the jobs on those patches with limited resources > > > > > > > >> results > > > > > > > >> in: > > > > > > > >> overloaded resources, slow response time, unhappy developers. > > > > > > > >> > > > > > > > >> # Proposed Solution > > > > > > > >> > > > > > > > >> To run less jobs we know we don’t need to, thus making more > > > > > > > >> resources > > > > > > > >> for > > > > > > > >> the > > > > > > > >> jobs we need to run. > > > > > > > >> We have been experimenting to make our CI stabler and quicker to > > > > > > > >> respond > > > > > > > >> by > > > > > > > >> using gerrit flags. This has improved in both directions very > > > > > > > >> well > > > > > > > >> internally. > > > > > > > >> Now it seems a good time to let all the oVirt projects to use > > > > > > > >> this. > > > > > > > >> This solution indirectly promotes reviews and quick tests - “to > > > > > > > >> fail > > > > > > > >> early”, > > > > > > > >> yet full blown static code analysis and long tests to run “when > > > > > > > >> ready”. > > > > > > > >> > > > > > > > >> # How it works > > > > > > > >> > > > > > > > >> 2 new gerrit independent flags are added to gerrit. > > > > > > > >> > > > > > > > >> ## CI flag > > > > > > > >> > > > > > > > >> Will express patch CI status. Values: > > > > > > > >>  * +1 CI passed > > > > > > > >>  *  0 CI did not run yet > > > > > > > >>  * -1 CI failed > > > > > > > >> Permissions for setting: project maintainers (for special cases) > > > > > > > >> should > > > > > > > >> be > > > > > > > >> able to set/override (except Jenkins). > > > > > > > >> > > > > > > > >> ## Workflow flag > > > > > > > >> > > > > > > > >> Will express patch “workflow” state. Values: > > > > > > > >>  *  0 Work In Progress > > > > > > > >>  * +1 Ready For Review > > > > > > > >>  * +2 Ready For Merge > > > > > > > >> Permissions for setting: Owner can set +1, Project Maintainers > > > > > > > >> can > > > > > > > >> set > > > > > > > >> +2 > > > > > > > >> > > > > > > > >> ## Review + CI Integration: > > > > > > > >> > > > > > > > >> Merging [“Submit” button to appear] will require: Review+1, > > > > > > > >> CI+1, > > > > > > > >> Workflow+2 > > > > > > > >> Patch lifecycle now is: > > > > > > > >> --------------------------------------------------------------- > > > > > > > >> patch state   |owner     |reviewer |maintainer |CI tests |pass > > > > > > > >> --------------------------------------------------------------- > > > > > > > >> added/updated |-         |-        |-          |quick    |CI+1 > > > > > > > >> review        |Workflow+1|Review+1 |-          |heavy |CI+1 > > > > > > > >> merge ready   |-         |-        |Workflow+2 |gating   |CI+1 > > > > > > > >> merge         |-         |-        |merge      |merge    |CI+1 > > > > > > > >> > > > > > > > >> Changes from current workflow: > > > > > > > >> Owner only adds reviewers, now owner needs to set "Workflow+1" > > > > > > > >> for > > > > > > > >> the > > > > > > > >> patch > > > > > > > >> to be reviewed, and heavily auto-tested. > > > > > > > >> Maintainer now needs to set "Workflow+2" and wait for "Submit" > > > > > > > >> button > > > > > > > >> to > > > > > > > >> appear after CI has completed running gating tests. > > > > > > > >> > > > > > > > >> > > > > > > > >> Next step will be to automate merge the change after Workflow+2 > > > > > > > >> has > > > > > > > >> been > > > > > > > >> set > > > > > > > >> by the Maintainer and gating tests passed. > > > > > > > >> > > > > > > > >> > > > > > > > >> ## Why now? > > > > > > > >> > > > > > > > >> It is elimination of waste. The sooner - the better. > > > > > > > >> The solution has been used for a while and it works. > > > > > > > >> Resolving the problem without gerrit involved will lead to > > > > > > > >> adding > > > > > > > >> unreliable > > > > > > > >> code into jobs, and will still be prone to problems: > > > > > > > >>   Just recently, 3d ago we’ve tried detecting what to run from > > > > > > > >>   jenkins > > > > > > > >>   relying only on gerrit comments so that upon Verified+1, we’d > > > > > > > >>   run > > > > > > > >>   the > > > > > > > >>   job. > > > > > > > >>   We could not use “Review+1”, because it makes no sense at all, > > > > > > > >>   so > > > > > > > >>   we > > > > > > > >>   left > > > > > > > >>   the job to set Verified+1. > > > > > > > >>   Meaning - re-trigger itself immediately more than 1 times. > > > > > > > >>   > > > > > > > >>   Jenkins and its visitors very unhappy, and we had to stop > > > > > > > >>   those > > > > > > > >>   jobs, > > > > > > > >>   clean > > > > > > > >>   up the queue, and spam developers. > > > > > > > >> > > > > > > > >> ## OK OK OK. Now what? > > > > > > > >> > > > > > > > >> Now we want your comments and opinions before pushing this > > > > > > > >> further: > > > > > > > >> Please participate in this thread, so we can start trying it > > > > > > > >> out. > > > > > > > >> Ask, Suggest better ideas, all this is welcome. > > > > > > > >> > > > > > > > >> > > > > > > > >> Best Regards! > > > > > > > >> > > > > > > > >> > > > > > > > >> N.B. > > > > > > > >> Of course, this is not written in stone, in case we find a > > > > > > > >> better > > > > > > > >> approach > > > > > > > >> on > > > > > > > >> solving those issues, we will change to it. > > > > > > > >> And we will keep improving so don't be afraid that it will be > > > > > > > >> enforced: > > > > > > > >> if > > > > > > > >> this does not work out we will discard it. > > > > > > > >> > > > > > > > >> P.S. > > > > > > > >> Kudos to dcaro, most of the work was done by him, and most of > > > > > > > >> this > > > > > > > >> text > > > > > > > >> too. > > > > > > > >> > > > > > > > > > > > > > > > > +1 from me, releasing CI from running non critical and > > > > > > > > un-essential > > > > > > > > jobs > > > > > > > > will not only reduce load from ci, > > > > > > > > and shorted response time for developers, it will allow us to add > > > > > > > > much > > > > > > > > more > > > > > > > > powerful tests such as functional & system > > > > > > > > tests that actually add hosts and run VMs, improving our ability > > > > > > > > to > > > > > > > > find > > > > > > > > regression much more effectively. > > > > > > > > > > > > > > > > Another benefit to consider is saving reviewers time. I.e not > > > > > > > > only > > > > > > > > jenkins > > > > > > > > benefits from Worklow+1, but also human reviewers. > > > > > > > > Instead of looking at a patch that is too early to be reviewed, > > > > > > > > the > > > > > > > > author > > > > > > > > can set the Workflow+1 when the code is ready to review > > > > > > > > (even if he didn't verified it yet), thus saving time to other > > > > > > > > reviewers > > > > > > > > - > > > > > > > > for example people can add an email rule > > > > > > > > to alert them only when they are added to patches that have > > > > > > > > Workflow+1, > > > > > > > > and > > > > > > > > not before. > > > > > > > > > > > > > > For human reviewers I suggest to keep using drafts until the patch > > > > > > > is > > > > > > > finished. > > > > > > > > > > > > keep using? how many developers do you know are working with drafts > > > > > > until > > > > > > their patch is ready? > > > > > > i agree if everyone would use drafts load on jenkins was already much > > > > > > lower, > > > > > > unfortunately its not the case. > > > > > > > > > > > > > > > > IMO we don't need the "workflow" flag. > > > > > I'm okay with CI not running on "drafts". And yes... we do use them. > > > > > We can try and educate people to use them more where needed. > > > > > Drafts should be widely used in first-phase development, and less on > > > > > bug-fixes. > > > > > > > > > > In addition, I think the patch owners shouldn't add reviewers, unless > > > > > they > > > > > need their input in the stage of the development. > > > > > Once they want input, they should add reviewers. > > > > > > > > > > 1. So, if the patch is draft then no CI runs on it. > > > > > 2. Once it turns into non-draft, you can run "light-CI" on it. > > > > > 3. Once the patch has at least one +1 from a (human) reviewer, then it > > > > > should > > > > > run the "heavy" CI. > > > > > 4. Once the patch has +1 from heavy CI, and +2 from reviewer > > > > > (maintainer), > > > > > then it can be merged. > > > > > > > > > > That's the process we have today, with slight change on when to run the > > > > > CI > > > > > and what CI to run (no CI on drafts, light CI on non-draft, heavy CI on > > > > > +1 > > > > > patches). > > > > > > > > +1 > > > > > > > > This is he right approach to go (I am also using drafts and if other > > > > don't, > > > > we can change that....) > > > > Also, regarding the claim that publishing a draft is a one-way process, I > > > > don't think that this is problematic, you should publish a draft after it > > > > is > > > > stable and you addressed all comments and run all tests locally > > > > > > > > > > this might be true, but the problem is: > > >  1. we can't enforce people to use drafts (technically), so until they do, > > >  we'll still have a resource problem > > > > > > We can educate, and I don't see an issue with that. > > > > >  2. until we do, even "light ci" jobs running per patch will overload the > > >  ci > > >  without need, this is why relying on another > > >     flag will help - if adding workflow is a problem, we can use the CR+1 > > >     as > > >     first attempt to improve the flow, > > >     and consider in the future to use workflow if it will be needed. (maybe > > >     we can even set it automatically somehow) > > > > > > > Perhaps marking as "verified" can be this flag. > > If the patch is verified by the author, then you run light CI on it. > > If it was also CR+1, run the heavy CI. > > question is how soon does an author ticks verify on his patch? > does he wait for code review before? for e.g. - i heard from some developers they wait > for CI to give them +1 until they even add reviewers, so this might be the chicken and egg problem. It depends on the patch I guess. Again, I think drafts are enough, and that we shouldn't add another flag here, so suggesting alternatives for that. We can "vote" on that flag addition, and other alternatives, and see what people say. > > > > > That way you both don't need a new flag, and you don't waste resources on > > non-manually-verified bugs. > > > > > > > > > > > > > > > > > > > > > > > > Once it's finished and humans reviewed the logic of the patch, > > > > > > > Workflow+1 > > > > > > > should be triggered allowing automation to check the correctness of > > > > > > > the > > > > > > > patch. > > > > > > > IMHO there's no reason for wasting CI time on patches that will be > > > > > > > correct > > > > > > > from an automation point of view but nacked by reviewers. > > > > > > > Especially > > > > > > > if > > > > > > > the > > > > > > > patches are part of a big patchset. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > And one final note, for Workflow+2 -> this is a preparation for a > > > > > > > > gating > > > > > > > > system, like Zuul used by openstack, that in the future > > > > > > > > we might use as automatic merger pending passing a verification > > > > > > > > step. > > > > > > > > this > > > > > > > > will prevent errors that happen sometimes > > > > > > > > post merge due to conflicts or other issues, and will be another > > > > > > > > level > > > > > > > > of > > > > > > > > validation before final merge. > > > > > > > > But as max said, its all part of the plan and we'll test it of > > > > > > > > course > > > > > > > > before implementing to see its value. > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> Max Kovgan > > > > > > > >> > > > > > > > >> Senior Software Engineer > > > > > > > >> Red Hat - EMEA ENG Virtualization R&D > > > > > > > >> Tel.: +972 9769 2060 > > > > > > > >> Email: mkovgan [at] redhat [dot] com > > > > > > > >> Web: http://www.redhat.com > > > > > > > >> RHT Global #: 82-72060 > > > > > > > >> > > > > > > > >> _______________________________________________ > > > > > > > >> 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Sandro Bonazzola > > > > > > > Better technology. Faster innovation. Powered by community > > > > > > > collaboration. > > > > > > > See how it works at redhat.com > > > > > > > _______________________________________________ > > > > > > > Infra mailing list > > > > > > > Infra(a)ovirt.org > > > > > > > http://lists.ovirt.org/mailman/listinfo/infra > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Devel mailing list > > > > > > Devel(a)ovirt.org > > > > > > http://lists.ovirt.org/mailman/listinfo/devel > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Infra mailing list > > > > > Infra(a)ovirt.org > > > > > http://lists.ovirt.org/mailman/listinfo/infra > > > > > > > > > _______________________________________________ > > > > Infra mailing list > > > > Infra(a)ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/infra > > > > > > > > > > > > > > > _______________________________________________ > > > Infra mailing list > > > Infra(a)ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/infra > > > > > _______________________________________________ > > Infra mailing list > > Infra(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > > > > > > _______________________________________________ > 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 _______________________________________________ Infra mailing list Infra(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/infra

For now can we agree that we want the ci flag at least?

On 06/07, Oved Ourfali wrote: > > On Jun 7, 2015 10:00 AM, Eyal Edri <eedri(a)redhat.com&gt; wrote: >> >> >> >> ----- Original Message ----- >>> From: "Oved Ourfali" <ovedo(a)redhat.com&gt; >>> To: "Eyal Edri" <eedri(a)redhat.com&gt; >>> Cc: infra(a)ovirt.org, devel(a)ovirt.org >>> Sent: Sunday, June 7, 2015 9:55:56 AM >>> Subject: Re: [ovirt-devel] gerrit+ci improvement proposal >>> >>> >>> >>> ----- Original Message ----- >>>> From: "Eyal Edri" <eedri(a)redhat.com&gt; >>>> To: "Eli Mesika" <emesika(a)redhat.com&gt; >>>> Cc: "Oved Ourfali" <ovedo(a)redhat.com&gt;, devel(a)ovirt.org, infra(a)ovirt.org >>>> Sent: Sunday, June 7, 2015 9:52:15 AM >>>> Subject: Re: [ovirt-devel] gerrit+ci improvement proposal >>>> >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Eli Mesika" <emesika(a)redhat.com&gt; >>>>> To: "Oved Ourfali" <ovedo(a)redhat.com&gt; >>>>> Cc: "Eyal Edri" <eedri(a)redhat.com&gt;, infra(a)ovirt.org, devel(a)ovirt.org >>>>> Sent: Thursday, June 4, 2015 3:49:05 PM >>>>> Subject: Re: [ovirt-devel] gerrit+ci improvement proposal >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Oved Ourfali" <ovedo(a)redhat.com&gt; >>>>>> To: "Eyal Edri" <eedri(a)redhat.com&gt; >>>>>> Cc: devel(a)ovirt.org, infra(a)ovirt.org >>>>>> Sent: Thursday, June 4, 2015 10:03:02 AM >>>>>> Subject: Re: [ovirt-devel] gerrit+ci improvement proposal >>>>>> >>>>>> >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: "Eyal Edri" <eedri(a)redhat.com&gt; >>>>>>> To: "Sandro Bonazzola" <sbonazzo(a)redhat.com&gt; >>>>>>> Cc: infra(a)ovirt.org, devel(a)ovirt.org >>>>>>> Sent: Thursday, June 4, 2015 9:46:40 AM >>>>>>> Subject: Re: [ovirt-devel] gerrit+ci improvement proposal >>>>>>> >>>>>>> >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>>> From: "Sandro Bonazzola" <sbonazzo(a)redhat.com&gt; >>>>>>>> To: "Eyal Edri" <eedri(a)redhat.com&gt;, "Max Kovgan" >>>>>>>> <mkovgan(a)redhat.com&gt; >>>>>>>> Cc: devel(a)ovirt.org, infra(a)ovirt.org >>>>>>>> Sent: Thursday, June 4, 2015 9:11:10 AM >>>>>>>> Subject: Re: [ovirt-devel] gerrit+ci improvement proposal >>>>>>>> >>>>>>>> Il 03/06/2015 21:46, Eyal Edri ha scritto: >>>>>>>>> >>>>>>>>> >>>>>>>>> ----- Original Message ----- >>>>>>>>>> From: "Max Kovgan" <mkovgan(a)redhat.com&gt; >>>>>>>>>> To: devel(a)ovirt.org >>>>>>>>>> Cc: infra(a)ovirt.org >>>>>>>>>> Sent: Wednesday, June 3, 2015 8:22:54 PM >>>>>>>>>> Subject: [ovirt-devel] gerrit+ci improvement proposal >>>>>>>>>> >>>>>>>>>> Hi everyone! >>>>>>>>>> We really want to have reliable and snappy CI: to allow short >>>>>>>>>> cycles >>>>>>>>>> and >>>>>>>>>> encourage developers to write tests. >>>>>>>>>> >>>>>>>>>> # Problem >>>>>>>>>> >>>>>>>>>> Many patches are neither ready for review nor for CI upon >>>>>>>>>> submission, >>>>>>>>>> which >>>>>>>>>> is OK. >>>>>>>>>> But running all the jobs on those patches with limited resources >>>>>>>>>> results >>>>>>>>>> in: >>>>>>>>>> overloaded resources, slow response time, unhappy developers. >>>>>>>>>> >>>>>>>>>> # Proposed Solution >>>>>>>>>> >>>>>>>>>> To run less jobs we know we don’t need to, thus making more >>>>>>>>>> resources >>>>>>>>>> for >>>>>>>>>> the >>>>>>>>>> jobs we need to run. >>>>>>>>>> We have been experimenting to make our CI stabler and quicker to >>>>>>>>>> respond >>>>>>>>>> by >>>>>>>>>> using gerrit flags. This has improved in both directions very >>>>>>>>>> well >>>>>>>>>> internally. >>>>>>>>>> Now it seems a good time to let all the oVirt projects to use >>>>>>>>>> this. >>>>>>>>>> This solution indirectly promotes reviews and quick tests - “to >>>>>>>>>> fail >>>>>>>>>> early”, >>>>>>>>>> yet full blown static code analysis and long tests to run “when >>>>>>>>>> ready”. >>>>>>>>>> >>>>>>>>>> # How it works >>>>>>>>>> >>>>>>>>>> 2 new gerrit independent flags are added to gerrit. >>>>>>>>>> >>>>>>>>>> ## CI flag >>>>>>>>>> >>>>>>>>>> Will express patch CI status. Values: >>>>>>>>>> * +1 CI passed >>>>>>>>>> * 0 CI did not run yet >>>>>>>>>> * -1 CI failed >>>>>>>>>> Permissions for setting: project maintainers (for special cases) >>>>>>>>>> should >>>>>>>>>> be >>>>>>>>>> able to set/override (except Jenkins). >>>>>>>>>> >>>>>>>>>> ## Workflow flag >>>>>>>>>> >>>>>>>>>> Will express patch “workflow” state. Values: >>>>>>>>>> * 0 Work In Progress >>>>>>>>>> * +1 Ready For Review >>>>>>>>>> * +2 Ready For Merge >>>>>>>>>> Permissions for setting: Owner can set +1, Project Maintainers >>>>>>>>>> can >>>>>>>>>> set >>>>>>>>>> +2 >>>>>>>>>> >>>>>>>>>> ## Review + CI Integration: >>>>>>>>>> >>>>>>>>>> Merging [“Submit” button to appear] will require: Review+1, >>>>>>>>>> CI+1, >>>>>>>>>> Workflow+2 >>>>>>>>>> Patch lifecycle now is: >>>>>>>>>> --------------------------------------------------------------- >>>>>>>>>> patch state |owner |reviewer |maintainer |CI tests |pass >>>>>>>>>> --------------------------------------------------------------- >>>>>>>>>> added/updated |- |- |- |quick |CI+1 >>>>>>>>>> review |Workflow+1|Review+1 |- |heavy |CI+1 >>>>>>>>>> merge ready |- |- |Workflow+2 |gating |CI+1 >>>>>>>>>> merge |- |- |merge |merge |CI+1 >>>>>>>>>> >>>>>>>>>> Changes from current workflow: >>>>>>>>>> Owner only adds reviewers, now owner needs to set "Workflow+1" >>>>>>>>>> for >>>>>>>>>> the >>>>>>>>>> patch >>>>>>>>>> to be reviewed, and heavily auto-tested. >>>>>>>>>> Maintainer now needs to set "Workflow+2" and wait for "Submit" >>>>>>>>>> button >>>>>>>>>> to >>>>>>>>>> appear after CI has completed running gating tests. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Next step will be to automate merge the change after Workflow+2 >>>>>>>>>> has >>>>>>>>>> been >>>>>>>>>> set >>>>>>>>>> by the Maintainer and gating tests passed. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ## Why now? >>>>>>>>>> >>>>>>>>>> It is elimination of waste. The sooner - the better. >>>>>>>>>> The solution has been used for a while and it works. >>>>>>>>>> Resolving the problem without gerrit involved will lead to >>>>>>>>>> adding >>>>>>>>>> unreliable >>>>>>>>>> code into jobs, and will still be prone to problems: >>>>>>>>>> Just recently, 3d ago we’ve tried detecting what to run from >>>>>>>>>> jenkins >>>>>>>>>> relying only on gerrit comments so that upon Verified+1, we’d >>>>>>>>>> run >>>>>>>>>> the >>>>>>>>>> job. >>>>>>>>>> We could not use “Review+1”, because it makes no sense at all, >>>>>>>>>> so >>>>>>>>>> we >>>>>>>>>> left >>>>>>>>>> the job to set Verified+1. >>>>>>>>>> Meaning - re-trigger itself immediately more than 1 times. >>>>>>>>>> >>>>>>>>>> Jenkins and its visitors very unhappy, and we had to stop >>>>>>>>>> those >>>>>>>>>> jobs, >>>>>>>>>> clean >>>>>>>>>> up the queue, and spam developers. >>>>>>>>>> >>>>>>>>>> ## OK OK OK. Now what? >>>>>>>>>> >>>>>>>>>> Now we want your comments and opinions before pushing this >>>>>>>>>> further: >>>>>>>>>> Please participate in this thread, so we can start trying it >>>>>>>>>> out. >>>>>>>>>> Ask, Suggest better ideas, all this is welcome. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Best Regards! >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> N.B. >>>>>>>>>> Of course, this is not written in stone, in case we find a >>>>>>>>>> better >>>>>>>>>> approach >>>>>>>>>> on >>>>>>>>>> solving those issues, we will change to it. >>>>>>>>>> And we will keep improving so don't be afraid that it will be >>>>>>>>>> enforced: >>>>>>>>>> if >>>>>>>>>> this does not work out we will discard it. >>>>>>>>>> >>>>>>>>>> P.S. >>>>>>>>>> Kudos to dcaro, most of the work was done by him, and most of >>>>>>>>>> this >>>>>>>>>> text >>>>>>>>>> too. >>>>>>>>>> >>>>>>>>> >>>>>>>>> +1 from me, releasing CI from running non critical and >>>>>>>>> un-essential >>>>>>>>> jobs >>>>>>>>> will not only reduce load from ci, >>>>>>>>> and shorted response time for developers, it will allow us to add >>>>>>>>> much >>>>>>>>> more >>>>>>>>> powerful tests such as functional & system >>>>>>>>> tests that actually add hosts and run VMs, improving our ability >>>>>>>>> to >>>>>>>>> find >>>>>>>>> regression much more effectively. >>>>>>>>> >>>>>>>>> Another benefit to consider is saving reviewers time. I.e not >>>>>>>>> only >>>>>>>>> jenkins >>>>>>>>> benefits from Worklow+1, but also human reviewers. >>>>>>>>> Instead of looking at a patch that is too early to be reviewed, >>>>>>>>> the >>>>>>>>> author >>>>>>>>> can set the Workflow+1 when the code is ready to review >>>>>>>>> (even if he didn't verified it yet), thus saving time to other >>>>>>>>> reviewers >>>>>>>>> - >>>>>>>>> for example people can add an email rule >>>>>>>>> to alert them only when they are added to patches that have >>>>>>>>> Workflow+1, >>>>>>>>> and >>>>>>>>> not before. >>>>>>>> >>>>>>>> For human reviewers I suggest to keep using drafts until the patch >>>>>>>> is >>>>>>>> finished. >>>>>>> >>>>>>> keep using? how many developers do you know are working with drafts >>>>>>> until >>>>>>> their patch is ready? >>>>>>> i agree if everyone would use drafts load on jenkins was already much >>>>>>> lower, >>>>>>> unfortunately its not the case. >>>>>>> >>>>>> >>>>>> IMO we don't need the "workflow" flag. >>>>>> I'm okay with CI not running on "drafts". And yes... we do use them. >>>>>> We can try and educate people to use them more where needed. >>>>>> Drafts should be widely used in first-phase development, and less on >>>>>> bug-fixes. >>>>>> >>>>>> In addition, I think the patch owners shouldn't add reviewers, unless >>>>>> they >>>>>> need their input in the stage of the development. >>>>>> Once they want input, they should add reviewers. >>>>>> >>>>>> 1. So, if the patch is draft then no CI runs on it. >>>>>> 2. Once it turns into non-draft, you can run "light-CI" on it. >>>>>> 3. Once the patch has at least one +1 from a (human) reviewer, then it >>>>>> should >>>>>> run the "heavy" CI. >>>>>> 4. Once the patch has +1 from heavy CI, and +2 from reviewer >>>>>> (maintainer), >>>>>> then it can be merged. >>>>>> >>>>>> That's the process we have today, with slight change on when to run the >>>>>> CI >>>>>> and what CI to run (no CI on drafts, light CI on non-draft, heavy CI on >>>>>> +1 >>>>>> patches). >>>>> >>>>> +1 >>>>> >>>>> This is he right approach to go (I am also using drafts and if other >>>>> don't, >>>>> we can change that....) >>>>> Also, regarding the claim that publishing a draft is a one-way process, I >>>>> don't think that this is problematic, you should publish a draft after it >>>>> is >>>>> stable and you addressed all comments and run all tests locally >>>>> >>>> >>>> this might be true, but the problem is: >>>> 1. we can't enforce people to use drafts (technically), so until they do, >>>> we'll still have a resource problem >>> >>> >>> We can educate, and I don't see an issue with that. >>> >>>> 2. until we do, even "light ci" jobs running per patch will overload the >>>> ci >>>> without need, this is why relying on another >>>> flag will help - if adding workflow is a problem, we can use the CR+1 >>>> as >>>> first attempt to improve the flow, >>>> and consider in the future to use workflow if it will be needed. (maybe >>>> we can even set it automatically somehow) >>>> >>> >>> Perhaps marking as "verified" can be this flag. >>> If the patch is verified by the author, then you run light CI on it. >>> If it was also CR+1, run the heavy CI. >> >> question is how soon does an author ticks verify on his patch? >> does he wait for code review before? for e.g. - i heard from some developers they wait >> for CI to give them +1 until they even add reviewers, so this might be the chicken and egg problem. > > It depends on the patch I guess. > Again, I think drafts are enough, and that we shouldn't add another flag here, so suggesting alternatives for that. > We can "vote" on that flag addition, and other alternatives, and see what people say. > >> >>> >>> That way you both don't need a new flag, and you don't waste resources on >>> non-manually-verified bugs. >>> >>>>>> >>>>>> >>>>>> >>>>>>>> Once it's finished and humans reviewed the logic of the patch, >>>>>>>> Workflow+1 >>>>>>>> should be triggered allowing automation to check the correctness of >>>>>>>> the >>>>>>>> patch. >>>>>>>> IMHO there's no reason for wasting CI time on patches that will be >>>>>>>> correct >>>>>>>> from an automation point of view but nacked by reviewers. >>>>>>>> Especially >>>>>>>> if >>>>>>>> the >>>>>>>> patches are part of a big patchset. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> And one final note, for Workflow+2 -> this is a preparation for a >>>>>>>>> gating >>>>>>>>> system, like Zuul used by openstack, that in the future >>>>>>>>> we might use as automatic merger pending passing a verification >>>>>>>>> step. >>>>>>>>> this >>>>>>>>> will prevent errors that happen sometimes >>>>>>>>> post merge due to conflicts or other issues, and will be another >>>>>>>>> level >>>>>>>>> of >>>>>>>>> validation before final merge. >>>>>>>>> But as max said, its all part of the plan and we'll test it of >>>>>>>>> course >>>>>>>>> before implementing to see its value. >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Max Kovgan >>>>>>>>>> >>>>>>>>>> Senior Software Engineer >>>>>>>>>> Red Hat - EMEA ENG Virtualization R&D >>>>>>>>>> Tel.: +972 9769 2060 >>>>>>>>>> Email: mkovgan [at] redhat [dot] com >>>>>>>>>> Web: http://www.redhat.com >>>>>>>>>> RHT Global #: 82-72060 >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Sandro Bonazzola >>>>>>>> Better technology. Faster innovation. Powered by community >>>>>>>> collaboration. >>>>>>>> See how it works at redhat.com >>>>>>>> _______________________________________________ >>>>>>>> Infra mailing list >>>>>>>> Infra(a)ovirt.org >>>>>>>> http://lists.ovirt.org/mailman/listinfo/infra >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Devel mailing list >>>>>>> Devel(a)ovirt.org >>>>>>> http://lists.ovirt.org/mailman/listinfo/devel >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Infra mailing list >>>>>> Infra(a)ovirt.org >>>>>> http://lists.ovirt.org/mailman/listinfo/infra >>>>>> >>>>> _______________________________________________ >>>>> Infra mailing list >>>>> Infra(a)ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/infra >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Infra mailing list >>>> Infra(a)ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/infra >>>> >>> _______________________________________________ >>> Infra mailing list >>> Infra(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/infra >>> >>> >>> >> _______________________________________________ >> Devel mailing list >> Devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/devel >> >> > _______________________________________________ > Infra mailing list > Infra(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra _______________________________________________ Devel mailing list Devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/devel

----- Original Message ----- > From: "David Caro" <dcaroest(a)redhat.com&gt; > To: "Oved Ourfali" <oourfali(a)redhat.com&gt; > Cc: "Oved Ourfali" <ovedo(a)redhat.com&gt;, "Eyal Edri" <eedri(a)redhat.com&gt;, =

> Sent: Thursday, June 11, 2015 1:19:01 PM > Subject: Re: [ovirt-devel] gerrit+ci improvement proposal >=20 >=20 >=20 > For now can we agree that we want the ci flag at least? =20 We should not vote on the "how the system will be implemented", but on "what the system should do".

=20 >=20 > On 06/07, Oved Ourfali wrote: > >=20 > > On Jun 7, 2015 10:00 AM, Eyal Edri <eedri(a)redhat.com&gt; wrote: > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Oved Ourfali" <ovedo(a)redhat.com&gt; > > > > To: "Eyal Edri" <eedri(a)redhat.com&gt; > > > > Cc: infra(a)ovirt.org, devel(a)ovirt.org > > > > Sent: Sunday, June 7, 2015 9:55:56 AM > > > > Subject: Re: [ovirt-devel] gerrit+ci improvement proposal > > > >=20 > > > >=20 > > > >=20 > > > > ----- Original Message ----- > > > > > From: "Eyal Edri" <eedri(a)redhat.com&gt; > > > > > To: "Eli Mesika" <emesika(a)redhat.com&gt; > > > > > Cc: "Oved Ourfali" <ovedo(a)redhat.com&gt;, devel(a)ovirt.org, > > > > > infra(a)ovirt.org > > > > > Sent: Sunday, June 7, 2015 9:52:15 AM > > > > > Subject: Re: [ovirt-devel] gerrit+ci improvement proposal > > > > >=20 > > > > >=20 > > > > >=20 > > > > > ----- Original Message ----- > > > > > > From: "Eli Mesika" <emesika(a)redhat.com&gt; > > > > > > To: "Oved Ourfali" <ovedo(a)redhat.com&gt; > > > > > > Cc: "Eyal Edri" <eedri(a)redhat.com&gt;, infra(a)ovirt.org, > > > > > > devel(a)ovirt.org > > > > > > Sent: Thursday, June 4, 2015 3:49:05 PM > > > > > > Subject: Re: [ovirt-devel] gerrit+ci improvement proposal > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > ----- Original Message ----- > > > > > > > From: "Oved Ourfali" <ovedo(a)redhat.com&gt; > > > > > > > To: "Eyal Edri" <eedri(a)redhat.com&gt; > > > > > > > Cc: devel(a)ovirt.org, infra(a)ovirt.org > > > > > > > Sent: Thursday, June 4, 2015 10:03:02 AM > > > > > > > Subject: Re: [ovirt-devel] gerrit+ci improvement proposal > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > ----- Original Message ----- > > > > > > > > From: "Eyal Edri" <eedri(a)redhat.com&gt; > > > > > > > > To: "Sandro Bonazzola" <sbonazzo(a)redhat.com&gt; > > > > > > > > Cc: infra(a)ovirt.org, devel(a)ovirt.org > > > > > > > > Sent: Thursday, June 4, 2015 9:46:40 AM > > > > > > > > Subject: Re: [ovirt-devel] gerrit+ci improvement proposal > > > > > > > >=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Sandro Bonazzola" <sbonazzo(a)redhat.com&gt; > > > > > > > > > To: "Eyal Edri" <eedri(a)redhat.com&gt;, "Max Kovgan" > > > > > > > > > <mkovgan(a)redhat.com&gt; > > > > > > > > > Cc: devel(a)ovirt.org, infra(a)ovirt.org > > > > > > > > > Sent: Thursday, June 4, 2015 9:11:10 AM > > > > > > > > > Subject: Re: [ovirt-devel] gerrit+ci improvement propos=

> > > > > > > > >=20 > > > > > > > > > Il 03/06/2015 21:46, Eyal Edri ha scritto: > > > > > > > > > >=20 > > > > > > > > > >=20 > > > > > > > > > > ----- Original Message ----- > > > > > > > > > >> From: "Max Kovgan" <mkovgan(a)redhat.com&gt; > > > > > > > > > >> To: devel(a)ovirt.org > > > > > > > > > >> Cc: infra(a)ovirt.org > > > > > > > > > >> Sent: Wednesday, June 3, 2015 8:22:54 PM > > > > > > > > > >> Subject: [ovirt-devel] gerrit+ci improvement proposal > > > > > > > > > >>=20 > > > > > > > > > >> Hi everyone! > > > > > > > > > >> We really want to have reliable and snappy CI: to al=

> > > > > > > > > >> short > > > > > > > > > >> cycles > > > > > > > > > >> and > > > > > > > > > >> encourage developers to write tests. > > > > > > > > > >>=20 > > > > > > > > > >> # Problem > > > > > > > > > >>=20 > > > > > > > > > >> Many patches are neither ready for review nor for CI=

> > > > > > > > > >> submission, > > > > > > > > > >> which > > > > > > > > > >> is OK. > > > > > > > > > >> But running all the jobs on those patches with limit=

> > > > > > > > > >> resources > > > > > > > > > >> results > > > > > > > > > >> in: > > > > > > > > > >> overloaded resources, slow response time, unhappy > > > > > > > > > >> developers. > > > > > > > > > >>=20 > > > > > > > > > >> # Proposed Solution > > > > > > > > > >>=20 > > > > > > > > > >> To run less jobs we know we don=E2=80=99t need to, t=

> > > > > > > > > >> more > > > > > > > > > >> resources > > > > > > > > > >> for > > > > > > > > > >> the > > > > > > > > > >> jobs we need to run. > > > > > > > > > >> We have been experimenting to make our CI stabler and > > > > > > > > > >> quicker to > > > > > > > > > >> respond > > > > > > > > > >> by > > > > > > > > > >> using gerrit flags. This has improved in both direct=

> > > > > > > > > >> very > > > > > > > > > >> well > > > > > > > > > >> internally. > > > > > > > > > >> Now it seems a good time to let all the oVirt projec=

> > > > > > > > > >> use > > > > > > > > > >> this. > > > > > > > > > >> This solution indirectly promotes reviews and quick =

> > > > > > > > > >> - =E2=80=9Cto > > > > > > > > > >> fail > > > > > > > > > >> early=E2=80=9D, > > > > > > > > > >> yet full blown static code analysis and long tests t=

> > > > > > > > > >> =E2=80=9Cwhen > > > > > > > > > >> ready=E2=80=9D. > > > > > > > > > >>=20 > > > > > > > > > >> # How it works > > > > > > > > > >>=20 > > > > > > > > > >> 2 new gerrit independent flags are added to gerrit. > > > > > > > > > >>=20 > > > > > > > > > >> ## CI flag > > > > > > > > > >>=20 > > > > > > > > > >> Will express patch CI status. Values: > > > > > > > > > >>=C2=A0 * +1 CI passed > > > > > > > > > >>=C2=A0 *=C2=A0 0 CI did not run yet > > > > > > > > > >>=C2=A0 * -1 CI failed > > > > > > > > > >> Permissions for setting: project maintainers (for sp=

> > > > > > > > > >> cases) > > > > > > > > > >> should > > > > > > > > > >> be > > > > > > > > > >> able to set/override (except Jenkins). > > > > > > > > > >>=20 > > > > > > > > > >> ## Workflow flag > > > > > > > > > >>=20 > > > > > > > > > >> Will express patch =E2=80=9Cworkflow=E2=80=9D state.=

> > > > > > > > > >>=C2=A0 *=C2=A0 0 Work In Progress > > > > > > > > > >>=C2=A0 * +1 Ready For Review > > > > > > > > > >>=C2=A0 * +2 Ready For Merge > > > > > > > > > >> Permissions for setting: Owner can set +1, Project > > > > > > > > > >> Maintainers > > > > > > > > > >> can > > > > > > > > > >> set > > > > > > > > > >> +2 > > > > > > > > > >>=20 > > > > > > > > > >> ## Review + CI Integration: > > > > > > > > > >>=20 > > > > > > > > > >> Merging [=E2=80=9CSubmit=E2=80=9D button to appear] =

> > > > > > > > > >> Review+1, > > > > > > > > > >> CI+1, > > > > > > > > > >> Workflow+2 > > > > > > > > > >> Patch lifecycle now is: > > > > > > > > > >> ----------------------------------------------------=

> > > > > > > > > >> patch state=C2=A0=C2=A0 |owner=C2=A0=C2=A0=C2=A0=C2=

> > > > > > > > > >> |pass > > > > > > > > > >> ----------------------------------------------------=

> > > > > > > > > >> added/updated |-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=

> > > > > > > > > >> =C2=A0=C2=A0=C2=A0 |CI+1 > > > > > > > > > >> review=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |Wo=

> > > > > > > > > >> |CI+1 > > > > > > > > > >> merge ready=C2=A0=C2=A0 |-=C2=A0=C2=A0=C2=A0=C2=A0=

> > > > > > > > > >> =C2=A0=C2=A0 |CI+1 > > > > > > > > > >> merge=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=

> > > > > > > > > >> =C2=A0=C2=A0=C2=A0 |CI+1 > > > > > > > > > >>=20 > > > > > > > > > >> Changes from current workflow: > > > > > > > > > >> Owner only adds reviewers, now owner needs to set > > > > > > > > > >> "Workflow+1" > > > > > > > > > >> for > > > > > > > > > >> the > > > > > > > > > >> patch > > > > > > > > > >> to be reviewed, and heavily auto-tested. > > > > > > > > > >> Maintainer now needs to set "Workflow+2" and wait for > > > > > > > > > >> "Submit" > > > > > > > > > >> button > > > > > > > > > >> to > > > > > > > > > >> appear after CI has completed running gating tests. > > > > > > > > > >>=20 > > > > > > > > > >>=20 > > > > > > > > > >> Next step will be to automate merge the change after > > > > > > > > > >> Workflow+2 > > > > > > > > > >> has > > > > > > > > > >> been > > > > > > > > > >> set > > > > > > > > > >> by the Maintainer and gating tests passed. > > > > > > > > > >>=20 > > > > > > > > > >>=20 > > > > > > > > > >> ## Why now? > > > > > > > > > >>=20 > > > > > > > > > >> It is elimination of waste. The sooner - the better. > > > > > > > > > >> The solution has been used for a while and it works. > > > > > > > > > >> Resolving the problem without gerrit involved will l=

> > > > > > > > > >> adding > > > > > > > > > >> unreliable > > > > > > > > > >> code into jobs, and will still be prone to problems: > > > > > > > > > >>=C2=A0=C2=A0 Just recently, 3d ago we=E2=80=99ve trie=

> > > > > > > > > >>=C2=A0=C2=A0 from > > > > > > > > > >>=C2=A0=C2=A0 jenkins > > > > > > > > > >>=C2=A0=C2=A0 relying only on gerrit comments so that =

> > > > > > > > > >>=C2=A0=C2=A0 we=E2=80=99d > > > > > > > > > >>=C2=A0=C2=A0 run > > > > > > > > > >>=C2=A0=C2=A0 the > > > > > > > > > >>=C2=A0=C2=A0 job. > > > > > > > > > >>=C2=A0=C2=A0 We could not use =E2=80=9CReview+1=E2=80=

> > > > > > > > > >>=C2=A0=C2=A0 at all, > > > > > > > > > >>=C2=A0=C2=A0 so > > > > > > > > > >>=C2=A0=C2=A0 we > > > > > > > > > >>=C2=A0=C2=A0 left > > > > > > > > > >>=C2=A0=C2=A0 the job to set Verified+1. > > > > > > > > > >>=C2=A0=C2=A0 Meaning - re-trigger itself immediately =

> > > > > > > > > >>=C2=A0=C2=A0 times. > > > > > > > > > >>=C2=A0=C2=A0=20 > > > > > > > > > >>=C2=A0=C2=A0 Jenkins and its visitors very unhappy, a=

> > > > > > > > > >>=C2=A0=C2=A0 stop > > > > > > > > > >>=C2=A0=C2=A0 those > > > > > > > > > >>=C2=A0=C2=A0 jobs, > > > > > > > > > >>=C2=A0=C2=A0 clean > > > > > > > > > >>=C2=A0=C2=A0 up the queue, and spam developers. > > > > > > > > > >>=20 > > > > > > > > > >> ## OK OK OK. Now what? > > > > > > > > > >>=20 > > > > > > > > > >> Now we want your comments and opinions before pushin=

> > > > > > > > > >> further: > > > > > > > > > >> Please participate in this thread, so we can start t=

> > > > > > > > > >> it > > > > > > > > > >> out. > > > > > > > > > >> Ask, Suggest better ideas, all this is welcome. > > > > > > > > > >>=20 > > > > > > > > > >>=20 > > > > > > > > > >> Best Regards! > > > > > > > > > >>=20 > > > > > > > > > >>=20 > > > > > > > > > >> N.B. > > > > > > > > > >> Of course, this is not written in stone, in case we =

> > > > > > > > > >> better > > > > > > > > > >> approach > > > > > > > > > >> on > > > > > > > > > >> solving those issues, we will change to it. > > > > > > > > > >> And we will keep improving so don't be afraid that i=

> > > > > > > > > >> be > > > > > > > > > >> enforced: > > > > > > > > > >> if > > > > > > > > > >> this does not work out we will discard it. > > > > > > > > > >>=20 > > > > > > > > > >> P.S. > > > > > > > > > >> Kudos to dcaro, most of the work was done by him, an=

> > > > > > > > > >> of > > > > > > > > > >> this > > > > > > > > > >> text > > > > > > > > > >> too. > > > > > > > > > >>=20 > > > > > > > > > >=20 > > > > > > > > > > +1 from me, releasing CI from running non critical and > > > > > > > > > > un-essential > > > > > > > > > > jobs > > > > > > > > > > will not only reduce load from ci, > > > > > > > > > > and shorted response time for developers, it will all=

> > > > > > > > > > to add > > > > > > > > > > much > > > > > > > > > > more > > > > > > > > > > powerful tests such as functional & system > > > > > > > > > > tests that actually add hosts and run VMs, improving =

> > > > > > > > > > ability > > > > > > > > > > to > > > > > > > > > > find > > > > > > > > > > regression much more effectively. > > > > > > > > > >=20 > > > > > > > > > > Another benefit to consider is saving reviewers time.=

> > > > > > > > > > not > > > > > > > > > > only > > > > > > > > > > jenkins > > > > > > > > > > benefits from Worklow+1, but also human reviewers. > > > > > > > > > > Instead of looking at a patch that is too early to be > > > > > > > > > > reviewed, > > > > > > > > > > the > > > > > > > > > > author > > > > > > > > > > can set the Workflow+1 when the code is ready to revi=

> > > > > > > > > > (even if he didn't verified it yet), thus saving time=

> > > > > > > > > > other > > > > > > > > > > reviewers > > > > > > > > > > - > > > > > > > > > > for example people can add an email rule > > > > > > > > > > to alert them only when they are added to patches tha=

> > > > > > > > > > Workflow+1, > > > > > > > > > > and > > > > > > > > > > not before. > > > > > > > > >=20 > > > > > > > > > For human reviewers I suggest to keep using drafts unti=

> > > > > > > > > patch > > > > > > > > > is > > > > > > > > > finished. > > > > > > > >=20 > > > > > > > > keep using? how many developers do you know are working w=

> > > > > > > > drafts > > > > > > > > until > > > > > > > > their patch is ready? > > > > > > > > i agree if everyone would use drafts load on jenkins was > > > > > > > > already much > > > > > > > > lower, > > > > > > > > unfortunately its not the case. > > > > > > > >=20 > > > > > > >=20 > > > > > > > IMO we don't need the "workflow" flag. > > > > > > > I'm okay with CI not running on "drafts". And yes... we do =

> > > > > > > them. > > > > > > > We can try and educate people to use them more where needed. > > > > > > > Drafts should be widely used in first-phase development, an=

> > > > > > > on > > > > > > > bug-fixes. > > > > > > >=20 > > > > > > > In addition, I think the patch owners shouldn't add reviewe=

> > > > > > > unless > > > > > > > they > > > > > > > need their input in the stage of the development. > > > > > > > Once they want input, they should add reviewers. > > > > > > >=20 > > > > > > > 1. So, if the patch is draft then no CI runs on it. > > > > > > > 2. Once it turns into non-draft, you can run "light-CI" on =

> > > > > > > 3. Once the patch has at least one +1 from a (human) review=

> > > > > > > then it > > > > > > > should > > > > > > > run the "heavy" CI. > > > > > > > 4. Once the patch has +1 from heavy CI, and +2 from reviewer > > > > > > > (maintainer), > > > > > > > then it can be merged. > > > > > > >=20 > > > > > > > That's the process we have today, with slight change on whe=

> > > > > > > run the > > > > > > > CI > > > > > > > and what CI to run (no CI on drafts, light CI on non-draft,=

> > > > > > > CI on > > > > > > > +1 > > > > > > > patches). > > > > > >=20 > > > > > > +1 > > > > > >=20 > > > > > > This is he right approach to go (I am also using drafts and if > > > > > > other > > > > > > don't, > > > > > > we can change that....) > > > > > > Also, regarding the claim that publishing a draft is a one-way > > > > > > process, I > > > > > > don't think that this is problematic, you should publish a dr=

> > > > > > after it > > > > > > is > > > > > > stable and you addressed all comments and run all tests local=

> > > > > >=20 > > > > >=20 > > > > > this might be true, but the problem is: > > > > >=C2=A0 1. we can't enforce people to use drafts (technically), s=

> > > > >=C2=A0 they do, > > > > >=C2=A0 we'll still have a resource problem > > > >=20 > > > >=20 > > > > We can educate, and I don't see an issue with that. > > > >=20 > > > > >=C2=A0 2. until we do, even "light ci" jobs running per patch wi=

> > > > >=C2=A0 the > > > > >=C2=A0 ci > > > > >=C2=A0 without need, this is why relying on another > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 flag will help - if adding workflow is =

> > > > >=C2=A0=C2=A0=C2=A0=C2=A0 CR+1 > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 as > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 first attempt to improve the flow, > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 and consider in the future to use workf=

> > > > >=C2=A0=C2=A0=C2=A0=C2=A0 (maybe > > > > >=C2=A0=C2=A0=C2=A0=C2=A0 we can even set it automatically someho=

> > > > >=20 > > > >=20 > > > > Perhaps marking as "verified" can be this flag. > > > > If the patch is verified by the author, then you run light CI on =

> > > > If it was also CR+1, run the heavy CI. > > > > > > question is how soon does an author ticks verify on his patch? > > > does he wait for code review before? for e.g. - i heard from some > > > developers they wait > > > for CI to give them +1 until they even add reviewers, so this might=

> > > the chicken and egg problem. > >=20 > > It depends on the patch I guess. > > Again, I think drafts are enough, and that we shouldn't add another =

> > here, so suggesting alternatives for that. > > We can "vote" on that flag addition, and other alternatives, and see =

> > people say. > >=20 > > > > > > >=20 > > > > That way you both don't need a new flag, and you don't waste reso=

> > > > on > > > > non-manually-verified bugs. > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > > > Once it's finished and humans reviewed the logic of the > > > > > > > > > patch, > > > > > > > > > Workflow+1 > > > > > > > > > should be triggered allowing automation to check the > > > > > > > > > correctness of > > > > > > > > > the > > > > > > > > > patch. > > > > > > > > > IMHO there's no reason for wasting CI time on patches t=

> > > > > > > > > will be > > > > > > > > > correct > > > > > > > > > from an automation point of view but nacked by reviewer=

> > > > > > > > > Especially > > > > > > > > > if > > > > > > > > > the > > > > > > > > > patches are part of a big patchset. > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > >=20 > > > > > > > > > > And one final note, for Workflow+2 -> this is a prepa=

> > > > > > > > > > for a > > > > > > > > > > gating > > > > > > > > > > system, like Zuul used by openstack, that in the futu=

> > > > > > > > > > we might use as automatic merger pending passing a > > > > > > > > > > verification > > > > > > > > > > step. > > > > > > > > > > this > > > > > > > > > > will prevent errors that happen sometimes > > > > > > > > > > post merge due to conflicts or other issues, and will=

> > > > > > > > > > another > > > > > > > > > > level > > > > > > > > > > of > > > > > > > > > > validation before final merge. > > > > > > > > > > But as max said, its all part of the plan and we'll t=

> > > > > > > > > > of > > > > > > > > > > course > > > > > > > > > > before implementing to see its value. > > > > > > > > > >=20 > > > > > > > > > >=20 > > > > > > > > > >>=20 > > > > > > > > > >>=20 > > > > > > > > > >>=20 > > > > > > > > > >> Max Kovgan > > > > > > > > > >>=20 > > > > > > > > > >> Senior Software Engineer > > > > > > > > > >> Red Hat - EMEA ENG Virtualization R&D > > > > > > > > > >> Tel.: +972 9769 2060 > > > > > > > > > >> Email: mkovgan [at] redhat [dot] com > > > > > > > > > >> Web: http://www.redhat.com > > > > > > > > > >> RHT Global #: 82-72060 > > > > > > > > > >>=20 > > > > > > > > > >> _______________________________________________ > > > > > > > > > >> 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 > > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > -- > > > > > > > > > Sandro Bonazzola > > > > > > > > > Better technology. Faster innovation. Powered by commun=

> > > > > > > > > collaboration. > > > > > > > > > See how it works at redhat.com > > > > > > > > > _______________________________________________ > > > > > > > > > Infra mailing list > > > > > > > > > Infra(a)ovirt.org > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/infra > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > _______________________________________________ > > > > > > > > Devel mailing list > > > > > > > > Devel(a)ovirt.org > > > > > > > > http://lists.ovirt.org/mailman/listinfo/devel > > > > > > > >=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > > _______________________________________________ > > > > > > > Infra mailing list > > > > > > > Infra(a)ovirt.org > > > > > > > http://lists.ovirt.org/mailman/listinfo/infra > > > > > > >=20 > > > > > > _______________________________________________ > > > > > > Infra mailing list > > > > > > Infra(a)ovirt.org > > > > > > http://lists.ovirt.org/mailman/listinfo/infra > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > _______________________________________________ > > > > > Infra mailing list > > > > > Infra(a)ovirt.org > > > > > http://lists.ovirt.org/mailman/listinfo/infra > > > > >=20 > > > > _______________________________________________ > > > > Infra mailing list > > > > Infra(a)ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/infra > > > >=20 > > > >=20 > > > >=20 > > > _______________________________________________ > > > Devel mailing list > > > Devel(a)ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/devel > > > > > > > > _______________________________________________ > > Infra mailing list > > Infra(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra >=20 > -- > David Caro >=20 > Red Hat S.L. > Continuous Integration Engineer - EMEA ENG Virtualization R&D >=20 > Tel.: +420 532 294 605 > Email: dcaro(a)redhat.com > Web: www.redhat.com > RHT Global #: 82-62605 >=20 > _______________________________________________ > Infra mailing list > Infra(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra >=20

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVeZ2nAAoJEEBxx+HSYmnDTXAH/ROekk+O92yyt+Uoa28Q8gjR aQNbFAGnVnxeidTOWn6q9osaa1E+3V6d4w0ZSp3YB6gR1kUJms7qTxmhPuMqwq/b pILZA6P37hMEL3fa2tQRGm06ccYiIH6ZL6GkYrG5oc5+3n6GvUyB2UqMXAaR/zqu YkxTKOcPgssKg8ncwrVnNFIP2hMT7rEGrb1CWPVsROvjvo2dMogUMj8m8XitXXPE Q0EQ7/B9BhMJZZES+6VuHBDJV2wO8G+zazj3BNYZvGjZlpojue185pX9n+4joULN dUtNw04x+RCJnb7lzYRdJtxL/SqndX4zsXwNaTKh5yzVqbV2wWa0xdU4YCGGJls= =lXz0 -----END PGP SIGNATURE-----