Re: Squid3: schedule and naming

From: Amos Jeffries <squid3@dont-contact.us>
Date: Wed, 8 Aug 2007 17:35:56 +1200 (NZST)

> On Tue, 2007-08-07 at 20:22 +1200, Amos Jeffries wrote:
>
>> We are only waiting on two blocker bugs now before 3.0 or PRE7.
>> How soon? and which? I'm just so impatient to know :-)
>
> I think the next release should be RC1, but I do not have a strong
> opinion. It should happen after there are no blockers left. I think
> there has been good progress on both of the existing two blockers, so I
> hope they will be closed this week.
>
> Alex.
>

I just spent the afternoon going over Christos full patch for
squid3-largeobj and only found a few very minor things. Though I still
don't know squid well enough to tell if there is anything missed out.

Christos:
 The bits I picked out are below. And feel free to tell me I'm wrong, you
are the expert here.

HttpHdrRange.cc chunk @459
 - (uint64_t) looks to be obsolete cast now in the if.

Not sure whether these are needed, but its not clear either way without a
compile test.
peer_digest.cc chunk @787
 - (int)
store_dir.cc chunk @330
 - (uint64_t )

Some formatting niggles:
access_log.cc chunk @531
- outoff, and dooff definitions are indented with tab, needs to be space.

src/Makefile.am chunk @584
 - makefiles are all tab indented. StoreMetaSTDLFS.h has been spaced.
(yes its weird, but I think its a carryover from an automake syntax
requirement)

ufsdump.cc chunk @89
- I would suggest doing a single static_cast in each of your cases and
then using the converted pointer. You will need to add {}. That drops 6
castings down to 2 and makes it more readable.
- Also, anything streamed should not need casting unless its stored wrong
(the "(int)x.getType()" )

not bad for such a large amount of work.
Thank you, most definately.

Amos
Received on Tue Aug 07 2007 - 23:36:03 MDT

This archive was generated by hypermail pre-2.1.9 : Fri Aug 31 2007 - 12:00:05 MDT