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

Hi,

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
>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

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.

Guido

> * 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

-
=======================================================
Serassio Guido
Via Albenga, 11/4 10134 - Torino - ITALY
E-mail: guido.serassio@serassio.it
WWW: http://www.serassio.it
Received on Thu Apr 04 2002 - 05:16:47 MST