Re: Squid-2.6 merge fest, and policy (cleanup time)

From: Guido Serassio <>
Date: Thu, 04 Apr 2002 13:16:41 +0100


Il 01.13 04/04/2002 Henrik Nordstrom ha scritto:
>As Squid-2.5 is now more or less out the door it is now time to start
>considering what should go into Squid-2.6.
>As suggested earlier I think Squid-2.6 should mainly be a feature
>release, incorporating most of the features we already have collected
>Squid-2.7 is then open for more ground-breaking changes, like what
>Adrian is currently up to with delegating the store lookup
>responsibility down ot the store..
>What I see as more or less immediate merge candidates for 2.6:
> * chunked mem pools
> * satellite enhancements, for more efficient peerings over large RTT
> * winbind
> * carp
> * ssl-nohttp
> * cbdata
> * rcdata, and to clean up relevant pieces of the code to use this in
>favor of abusing cbdata..
> * unix_sockets
> * external_acl
> * etag (currently broken due to the store API changes, and some of
>it will need to be rewritten again in 2.7)
> * cf_preprocess
>and I know some of you would like to see rproxy merged, but I will
>intentionally keep this as a patch for now. Maybe in 2.7.
>Branches & features I'd like to see as 2.6 merge candidates, but
>which I am not sure about their status:
> * te + te_modules.
> * authinfo (needs rewrite to fit new auth model)
> * ipv6
> * external_logger, but only as an option...
> * range processing, currently disabled in HEAD..
>Branches I do not know but which may have interesting stuff suitable
>for merging?
> * various parts of the native NT port

The 2.5 native NT port (nt-2.5) is running from some weeks. It seems to be
more stable then what I'm expect, but the code intrusion in same source
files (main.c, ipc.c, comm_select.c and others) is very heavy.
The modularization of ipc.c interface may help the code maintenance.

> * cygwin

At this time the cygwin branch is only the start point of cygwin-svc.
Thanks to the Robert works many features are now native in cygwin environment.

> * cygwin-svc

The cygwin-svc branch code was the start point for the nt-2.5 branch, and
it seems to be stable. Like nt-2.5, the code intrusion in main.c is heavy.

On the merge side, nt-2.5 and cygwin-svc must be merged integrally, because
all the new functionality are interdependent.


> * auth_rewrite (there is some digest stuff..??)
> * storecheck
> * push
>For 2.7 I'd like to see at least
> * Store rewritten to use async lookups, and per-directory index
>capabilities (hint: CARP:ify the store lookups)
> * compactsentry, to further reduce the memory overhead of the store
>index (whatever being left of it after the store reorganisation)
> * ipv6
>Anything forgotten above?
>As part of this I will also close down all finished projects on
>SourceForge, most likely including auth_rewrite (ntlm will then be
>moved as a sibling of HEAD), and reorganise the projects page in
>"Active", "Inactive" and "Finished" projects. If new developments are
>to be done in a previously closed branch then simply reopen the
>branch, or create a new one if the direction of the new development
>is slightly different (most often preferred).
>The intentions with the branched developments is that branches should
>be created when needed for a development effort, not to be kept
>indefinitely just in case.
>Ideally the development cycle of a branch is
>1. The need is identifed, and a outline documented
>2. A branch is created
>3. Development, testing and documentation until satisfied
>4. Review
>5. Branch closed and merged into HEAD
>If new need arise after 5 or development is ready to continue with a
>new aspect, then the procedure starts over for the new need/aspect.

Serassio Guido
Via Albenga, 11/4 10134 - Torino - ITALY
Received on Thu Apr 04 2002 - 05:16:47 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:14:57 MST