Squid-2.6 merge fest, and devel.squid-cache.org policy (cleanup time)

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
on devel.squid-cache.org.

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
links
 * 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
 * cygwin
 * cygwin-svc
 * 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.

Regards
Henrik
Received on Wed Apr 03 2002 - 17:14:34 MST