Re: Squid 3.5 release timetable

Sounds good to me.

On Fri, Jul 25, 2014 at 6:37 AM, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
> As luck would have it today is exactly 1 year since the first patch was
> held in trunk for 3.5 series release.
>
> Below is my current plan. Any objections please speak up.
>
>
> 1) Branching:
>
> I hope this can be done next weekend. August 1-3, maybe the week after
> if there are delays.
>
> We have enough features to make it useful even though some of the larger
> projects have not made it in.
>
> However, to minimize work in stage-2 trunk needs to be relatively stable
> before this happens. If any of you have patches lined up for commit or
> about to be, please reply to this mail with details so we can triage
> what gets in and what can hold off in audit.
>
> Note that patches applied after branching may still get to 3.5, but will
> have to be stable in trunk first.
>
> Patches that are welcome any time:
> - documentation updates
> - security bug fixes
>
>
> 2) Documentation and stability testing
>
> After branching we need to do as much testing as we can throw at the new
> branch and update any missing documentation.
>
> Most of the documentation is already done. So its just a scan through to
> check for missing or incorrect bits.
>
>
> 3) 3.5.0.1
>
> I am hoping this can be done by the end of August. Will happen whenever
> step-2 is completed.
>
>
> Stable) as usual depends on bugs
>
> 2 bugs explicitly on 3.HEAD within the 3.5 development period are
> blocking stable release until fixed or determined non-critical.
>
> 12 major or higher bugs in 3.4 seem worthy of blocking 3.5 stable for a
> bit to get resolved.
>
> We have 60 other major bugs outstanding across all Squid versions that
> should be resolved ASAP if at all possible.
>
>
> ************
>
> Projects I am aware of that are potentially coming up for commit over
> this period:
>
> * Kerberos autoconf updates
> - assuming the current rewrite patch
>
> * PROXY protocol
> - assuming the current partial support patch
>
> * Peek-n-Splice
> - assuming it is relatively isolated changes and well tested already
>
> * StoreID via eCAP/ICAP
> - I'm not sure what this is waiting on.
>
>
> Amos

-- 
    Francesco