Re: [PATCH] remove squid-old.h

On 08/16/2012 02:49 PM, Kinkie wrote:
> On Thu, Aug 16, 2012 at 6:00 PM, Alex Rousskov
> <rousskov_at_measurement-factory.com> wrote:
>> On 08/16/2012 12:56 AM, Kinkie wrote:
>>>> I am guessing this is the patch that broke build in numerous places. I
>>>> am surprised it was not reverted upon the first signs of trouble. Here
>>>> are some of the errors that I see:
>>>
>>> Prior to committing I have run a test-builds.sh on my kubuntu machine
>>> and it turned out fine; apparently the more recent kernel and/or glibc
>>> and/or gcc triggers some more permissive include paths.
>>
>> AFAICT, the problems are related to missing #includes (a header that was
>> included via squid-old.h is no longer included). For example,
>> src/adaptation/ecap/MessageRep.cc is now missing protos.h, which
>> provides a urlParse() declaration.
>>
>> A test build that enables ssl_crtd or eCAP could not succeed so I am
>> guessing your test-builds.sh does not enable them. I did not check
>> whether any other features are affected.
>
> I agree, that is the expected source of problems right now.
> "My" test-builds.sh is actually the whole build farm, whose status is:
> CentOs-5, CentOS-5-icc, ubuntu-precise, debian-squeeze-arm,
> freebsd-6.4 (west), mandriva, debian-unsatable: OK.
> FreeBSD-9, OpenSUSE, MacOS-Leopard: fail due to problems in the Rock unit test
> FreeBSD-9-clang: fail due to strtoll being misdetected
> OpenBSD(all): fail due to library circular dependencies (Msg/CacheMgr)
> Freebsd-7.2 (east), debian-sid-clang: fail due to system issues
> Mswin: compat/ failing to completely fulfill its role.
>
> In other words, none in 15 tested platforms shows the issue that
> you're highlighting. If anything, this means that must the build tests
> must be furhter improved: what can't be seen can't be fixed, despite
> the best efforts one can put in place.
>
>> Will you fix those bugs or is it now our responsibility to clean up the
>> modules we care about?
>
> I constantly try not to break anything, and I certainly will take care
> about fixing what I can see to be broken, regardless of whether I
> broke it or someone else broke it. Unfortunately, in a 10k lines
> patch, something may be missed despite the best intentions and
> efforts.
>
> I understand your concern, and I understand your annoyance, but I
> would appreciate if you used a less blunt way to express them. I may
> be the lest talented one in the team, but this also means I'm willing
> to take on jobs that noone else in the team seems to be willing to
> take. I am one of the few not having any direct work-related interest
> in squid; I do my best to help and learn along the way. If I cause
> more problems than bring benefits, please let me know. I'll just
> relinquish my committer rights, and focus on other ways to help.

I am not annoyed at the failures -- we all commit broken code once in a
while, and there is currently no good way to prevent even simple build
failures.

I am somewhat annoyed that some failures result in commit reversal (with
unusable or contradictory information as to the reason for the reversal)
while others are not (even after detailed reasons have been provided),
but this is _not_ the reason I am asking who is responsible for fixing
trunk -- I do really need to know whether this is something I should be
working on (to avoid two different people working on the same bug).

As for being "too blunt", I apologize for any unintended offense. I
certainly did not mean to post anything offensive.

Thank you,

Alex.
Received on Fri Aug 17 2012 - 05:11:51 MDT