Re: Reorganizing the squid builds

>> Not really.
>> Some advance was made with the Elastic Axis plugin (skip over
>> disconnected nodes) but that plugin can't be used due to other bugs.
>
>
> Then the reason we had for 3.HEAD builds being separated still stands - we
> need to easily and clearly see which OS to target bug fixing towards. I am
> happy for the compiler-specific builds to be matrix'd though so at most we
> have one 3.HEAD job per OS indicating whether it builds on all compilers
> that systems users will be using.

ok. That's a step forward.

>>> They currently provide a false impression of instability and prevents us
>>> testing all stable versions against all nodes simply because the newer
>>> nodes
>>> will be for OS which the stable was never coded to build on properly (ie
>>> 3.1
>>> wont build on FreeBSD 9/10 after compiler changes). It would be good to
>>> have
>>> such a picture of the versions buildability but I hope we can avoid
>>> giving
>>> the impression that none of our stables ever work.
>>>
>>> I think it may be worth a try, but not removing the existing jobs until
>>> the
>>> new ones have a proven record of usefulness.
>>
>> How about dropping only relatively rare configurations? e.g. icc,
>> ALPHA-PATCH, old FreeBSD variants? That'd already go a long way
>> towards simplification without losing sight of the big picture.
>
> The only reason ALPHA-PATCH are not a matrix is that I could not find a way
> to propigate the uploaded file to all the matrix sub-jobs. It got uploaded
> and applied on the keystone build but the others all ran without the patch,
> with the obvious useless results.

I understand; that's why the job I plan to use has a branch as argument.
There are plugins which may make sending a patch possible, but I
haven't tried them out yet.
How big of a downside would it be to use a launchpad branch instead of
a patchfile?

-- 
    /kinkie