Fix To Include

Is something stuck with integration by the CI monkey.  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.
Case 17296 --> Fix To Include 2016-01-21 22:29
Case 17435 --> Fix To Include 2016-01-22 16:34

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?  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

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

>
> 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.
In addition we pay attention to some fast paths when people need it.

Do I answer your questions?

Stef

>> 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.

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.

        Marcus

>> 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.

I do not have the same process.

On Mon, Jan 25, 2016 at 12:07 AM, stepharo <[hidden email]> wrote:

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.




On Mon, Jan 25, 2016 at 1:25 AM, stepharo <[hidden email]> 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

Le 25/1/16 01:35, Ben Coman a écrit :
Yes this is why I do not use "fix to include" to tag issues when I'm not
integrating them
right away. Only for difficult ones I know the monkey gets strange and I
integrate fast.

>
>> 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.
Yes you should raise the point like that we pay attention and allocate
specific resources.