Re: Squid 2.8 Roadmap

Mark Nottingham wrote:
> Now that Adrian has moved his work to Lusca, it looks like the Squid 2.8 roadmap <http://wiki.squid-cache.org/RoadMap/Squid2> isn't reflecting reality (please correct me if I'm wrong, adri!).
>
> Although I don't want to accelerate 2.x work, nor get in the way of 3.x work, I think it would be good to solidify a lot of the improvements in 2.HEAD into a proper release, so that people don't have to run with a lot of patches from HEAD.
>
> In particular, I'd like to see the following patches in 2.8 (or 2.7STABLE, but AIUI that's not appropriate, in most cases).
>
> * Logging rewritten URLs - bug 2406
> * Make PEER_TCP_MAGIC_COUNT configurable - bug 2377
> * hier_code ACL - bug 2390
> * HTCP / extension method patches - by benno, including 1235[3-5], 12358, 12364, 1236[7,8], 12427, 1245[5,6] patches
> * 64bit crash with PURGE and HTCP - bug 2799
> * Add old entry back to async object - bug 2832
> * CLR segfault - bug 2788
> * Direct peer monitoring - bug 2643
> * Adjustable latency stats - bug 2345
> * Adjustable collapsed forwarding timeouts - bug 2504
> * Idempotent start - bug 2599
> * Configurable forward max tries - bug 2632
> * Request body buffering - bug 2420
> * HTCP logging - bug 2627
> * ignore must-revalidate - bug 2645
> * Aggressive caching - bug 2631
> * Don't make fatal() dump core - bug 2673
> * Make storeurl_rewriter work with Vary - bug 2678
> * Make miss_access a slow lookup - bug 2688
>
> I'm happy to help with documenting these, etc. as much as required, although I'm not really up to full release management. Any guidance, etc. would be helpful.
>
> WRT the roadmap, is the best thing to do to remove the current information and start collecting a list of applicable bugs? Or can we just give them a Milestone of 2.8 in bugzilla?
>
> Cheers,

I know I don't have a lot of say in this, but here is my 2c anyway...

If Henrik and you agree that 2.HEAD is stable enough for poduction use I
wont objects. Even while reaching a point that 2.8 might happen saddens
me, I can see that it might be needed.

I'm happy with simply renaming 2.HEAD -> 2.8 formally. But not really
with branching a new release. Opening HEAD again for a possible 2.9 is
IMO a bad idea.

Making 2.8 formally the terminal 2.x release while allowing the
possibility that its feature set is not as stone-fixed as earlier 2.x.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE7 or 3.0.STABLE21
   Current Beta Squid 3.1.0.15