Re: [RFC] 3.1 branching

Henrik Nordstrom wrote:
> On sön, 2008-09-14 at 03:26 +1200, Amos Jeffries wrote:
>
>> ### A way of making the code a bit deterministic?
>>
>> Unlike the earlier recursion race the asynccall timing race is a bit of
>> a nightmare to debug postmortem.. which will very likely cause many gray
>> hairs while trying to analyze debug reports..
>> "
>>
>> Is this cleared now Henrik?
>
> Not cleared, but Alex is pretty much ontop of things removing my
> concern. It's more a design comment than a reservation.
>
>> ### Code formatting
>>
>> A few issues still to be sorted out. Nothing major though. The
>> majority of HEAD can be formatted in an hour or so notice.
>>
>> - todo: make existing scripts recursive over entire sources.
>> - how to automate for commit enforcement in bzr
>> - how to fix access_log.cc output (maybe others with same issue)
>> - work pattern for propagation to branches.
>
> Do we need to automate and enforce formatting? Should be sufficient to
> run the formatting tools every now and then combined with inspecting the
> results.
>
> But yes, if the tree is to be reformatted then it's better done before
> branching to minimize the merge conflicts in later backports..
>
>> ### source layout
>>
>> Not a blocker for the branch. Though Alex if you wanted to get in
>> touch about the exact plan of attack I'll make the time to help out here.
>
> This is material for the next cycle I think.
>
>> ### bug zapping
>>
>> New Critical ones are now dead.
>> Only important ones now are shared with 3.0.
>
> bug zapping is not a blocker for branching. Branching is determined by
> the feature set and pending+upcoming feature merges.
>
> Regards
> Henrik
>

So it sounds like we are clear to start this immediately following a
source format and testing of HEAD.

Henrik, can you let me know what the branch tasks are that I have to
perform, and if there are any I don't have permissions for, when it
would be convenient for them to happen?

Amos

-- 
Please use Squid 2.7.STABLE4 or 3.0.STABLE9