[SSSD] [PATCH] BUILD: Add missing header file to tarball

Lukas Slebodnik lslebodn at redhat.com
Wed Mar 25 21:28:04 UTC 2015


On (25/03/15 12:09), Nikolai Kondrashov wrote:
>On 03/24/2015 05:47 PM, 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. 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.
>
>I agree that running on servers is more convenient and efficient for
>developers, if enough resources is provided. You basically don't have to care
>about maintaining your own environment and your machine is free to do
>something else.
>
I really appreciate you realized I was right. It took a year and we wasted
lot of time in heated discussion. But at least my prediction was right.
It wasn't good idea to have single script for two purposes.

>I don't like that our full test suite takes such a long time and that
>developers have to wait in the queue.
>
If I understand it correctly we all agree that nobody want to use CI script
on local machine. So we can drop this requirement and it will simplify a lot of
things.

As we are not limited by local use case we can rework script to suit better
to git-push use case. I briefly checked time of execution and the full test
suite takes approximatelly 20-25 minutes. We can change sequential evaluation
of tests to the parallel one. It was not possible due requirement for
local usage. (BTW there will be still posibility to run it locally
but it will not be so comfrtable)

The proposed sub-tests are:
* make-check-valgrind
* make-distcheck
* mock-build
* code coverage
* integration test (patches still on review)

The each sub-test will be tested on all currently supported platform.
rhel7, rhel6, debian_testing, fedora20, fedora_rawhide
BTW we shoudl test fedora 21 and fedora 22 as well

So we will need to dedicate 5 * 7 + 1 machines

The time of execution will reduce from 25 minutes to the time of slowest test,
which is curently make-distcheck and it takes approximately 4 minutes.

It will be 6.25 times faster, which is really good improvement.

LS



More information about the sssd-devel mailing list