Re: Reorganizing the squid builds

On 20/08/2013 9:42 p.m., Kinkie wrote:
>>> 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?

Moderate. We have the ALPHA-branch job, but the big thing is often tha I
am testing some submitted patch or bugfix experiment quickly and don't
want to create a whole branch for it. Whenever I create a branch for
experiments I invariabley end up with some success that gets stuck in
audit for days and holds other work up.

Amos
Received on Wed Aug 21 2013 - 06:05:32 MDT