On 03/24/2015 05:18 PM, Lukas Slebodnik wrote:
On (24/03/15 16:47), Pavel Reichl wrote:
> On 03/24/2015 04:33 PM, Lukas Slebodnik wrote:
>> On (24/03/15 16:25), Pavel Reichl wrote:
>>> On 03/24/2015 04:08 PM, Lukas Slebodnik wrote:
>>>> On (23/03/15 17:53), Jakub Hrozek wrote:
>>>>> On Mon, Mar 23, 2015 at 05:03:03PM +0200, Nikolai Kondrashov wrote:
>>>>>> On 03/23/2015 03:59 PM, Lukas Slebodnik wrote:
>>>>>>> On (23/03/15 14:47), Pavel Reichl wrote:
>>>>>>>> On 03/23/2015 02:43 PM, Lukas Slebodnik wrote:
>>>>>>>>> On (23/03/15 14:18), Jakub Hrozek wrote:
>>>>>>>>>> On Mon, Mar 23, 2015 at 02:07:12PM +0100, Lukas
Slebodnik wrote:
>>>>>>>>>>> ehlo,
>>>>>>>>>>>
>>>>>>>>>>> simple patch is attached.
>>>>>>>>>>>
>>>>>>>>>>> LS
>>>>>>>>>> Hm, the default CI test doesn't run
distcheck?
>>>>>>>>>>
>>>>>>>>>> I admit I haven't ran distcheck myself, but
was relying on the CI link
>>>>>>>>>> Pavel sent..
>>>>>>>>> That's the reason why I do not send link to CI
result as an author of the
>>>>>>>>> patch.
>>>>>>>>>
>>>>>>>>> In my opinion it's reviewer's task.
>>>>>>>>>
>>>>>>>>> LS
>>>>>>>> What would be different if Jakub ran CI himself?
>>>>>>>>
>>>>>>> If I had reviewd your patch i would have sent links to CI
result which
>>>>>>> run all test (including distcheck and mock build)
>>>>>> I tend to agree with Pavel here: trusting developer's CI
links might save us
>>>>>> some time. It doesn't replace the patch-specific testing,
where necessary, of
>>>>>> course.
>>>>> The best would be if there was some tool that would grab the patches
>>>>> automagically and run the CI tests..
>>>>>
>>>> If we want to safe a time then developers should run CI script locally
>>>> with enabled all tests.
>>> I think it would make my VM for development busy for a couple dozens of
>>> minutes and I would have to limit my work on it. I would prefer to use lab
>>> machines on this task...
>> You can run test in VM with one core. It would take longer,
>> but it would not block you.
>>
>> You can also run CI script directly not PC with all available resources
>> if you do not use it (lunch break, ...)
> I don't think you are serious about that, are you? We should strive to make
> this process as developer friendly as possible.
Yes, I am serious.
I gave more options. So please stay technical and do not exaggerate.
I'm sorry
If you feel that way. I wasn't aware I was not technical and
exaggerating.
Nikolai put huge effort to make CI script user friendly also on local machine.
If it is not good enough for you please propose enhancements.
Lukas I never said
the it is not good enough for me. I just tried to
express that I am worried of running CI with all testes locally as you
proposed because it might take too many of my resources and it just
could take too long. I prefer the idea of shared VM pool for this task.
Running CI task that will take a couple of minutes locally is OK by me.
Any ideas how to speed up (improve) it are welcomed.
I proposed
the idea of sharing the result of CI between author and reviewer.
We can discuss it on next devel meeting.
> I find pushing to remote branch and letting lab handle the task great and
> if the pool is too small for the mass of tasks we should ask management
> to provide more resources rather then planning to run CI locally
> in lunch break
Please beavare of fact we don't have unlimited resources
and test suite will take longer after merging cwrap patches
and implementing more integration tests.
I'm aware of that. I'm just asking
if we reached the limit or if can expand.
Running script locally is especially useful when huge patch sets are pushed
to master and older branches. Post commit CI tests block machines
for long time.
>> Nikolai assumed developers will run script locally. It was already implemented
>> in the initial version. That was the time we shoudl complain
>> and change requirements and not year after.
> Well sometimes real usage differs from planed one, doesn't it?
That's the reason why he have desing documents and reviews.
It's to prevent putting effort to task which will not be usefull
or will never be used.
If we had known nobody it before we would have prevented flames on sssd-devel.
Please do not bikeshed and propose how to improve CI script.
Again, I'm sorry
that you feel that way. I hope that you now understand
my point.
LS
_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel