On Mon, Jan 25, 2016 at 12:07 AM, stepharo <[email protected]> wrote: > Hi ben >> >> Is something stuck with integration by the CI monkey. > > > Sometimes yes. Sometimes tests randomly failed on windows or something like > that :) >> >> I thought this automatically picked and integrated any Fix To Include >> status slices. >> But these two cases were marked Fix To include a fews days ago, and >> have not yet been integrated. > > No we (either esteban marcus and me look at the code) at least I try to > browse the code and click on a button. >> >> Case 17296 --> Fix To Include 2016-01-21 22:29 >> Case 17435 --> Fix To Include 2016-01-22 16:34 > > Fix to include are marked when we do not want that the monkey recheck them > to avoid that they get unttaged for integration. > > When I do an integration session like today for example. I tend to go slowly > and proceed with the domain I can understand. > So now I will do > > Case 17296
Thanks, I see its done. >> >> But I see several cases integrated since then didn't pass through Fix >> To Include, so I'm curious what the process is. Is it still a manual >> pick of items to integrate? > > Fix to include is just a marker to avoid endless verification of an issue. > Now this is not because a fix is reviewed by the monkey that he should be > automatically integrated. That is good to understand, and I agree. After reviewing someone else's slice, I have been wary of setting it Fix To Include assuming it *was* automatically integrated. Its good to know there'll be a final quick review by you guys (if indeed Marcus and Esteban operate the same way) However that if an issue is tagged Fix to Include on build 50538 and remains in that state through several builds to 50543 without further verification then this defeats a little bit the usefulness of the CI verification if some conflicting changes are introduced between 50538 and 50543. > In addition we pay attention to some fast paths when people need it. I understand. Mainly it was that it was opaque why my issue 17296 was stuck waiting, and I wait a few days before I ask. > > Do I answer your questions? > > Stef > >> In that case why are the above passed >> over? There is no indication on the tracker. >> >> Case 17429 --> Fix To include 2016-01-22 16:52 >> --> Integrated 2016-01-22 21:05 Build 50539 >> >> Case 17446 --> Fix To Include 2016-01-22 21:40 >> --> Integrated 2016-01-22 23:40 Build 50540 >> >> >> Case 17404 --> Fix Reviewed By Monkey 2016-01-24 03:42 >> Case 17443 --> Fix Reviewed By Monkey 2016-01-24 04:57 >> Case 17457 --> Fix Reviewed By Monkey 2016-01-24 05:03 >> --> Integrated 2016-01-24 17:55 Build 50541 >> >> Case 17450 --> Fix Review Needed 2016-01-24 19:37 >> --> Integrated 2016-01-24 17:37 Build 50542 >> >> Case 17301 --> Fix Reviewed by the Monkey 2016-01-24 20:39 >> Case 17384 --> Fix To Include 2016-01-24 16:50 >> --> Integrated 2016-01-24 20:39 Build 50543 On Mon, Jan 25, 2016 at 1:25 AM, stepharo <[email protected]> wrote: > >>> Fix to include are marked when we do not want that the monkey recheck >>> them to avoid that they get unttaged for integration. >> >> No, for me they are the ones to get integrated next. I always start with >> them. i never integrate anything that is not “fix to include”. >> >> I configured my integrator tool to not show my anything else. This way I >> am sure that I never integrate something wrong by mistake. So just to pin this down, did Case 17296 actually show up listed in the Integrator Tool between builds 50538 and 50543, and you've chosen to skip it due to time constraints? (which is okay.) Or didn't it show up? - in which case it would be good to understand why. > > I do not have the same process. It would be nice for there to be one process ;) I like Marcus' workflow. Its good for the project history to see who pushed an issue to Fix to Include. Doing this immediately before integration really shouldn't slow you down. The main thing is there is no visibility on the tracker of who ran the Integration Tool (and maybe that could be added sometime (low priority) ). cheers -ben
