httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <>
Subject [Fwd: Re: svn commit: r467655 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_cache.xml modules/cache/mod_cache.c modules/cache/mod_cache.h]
Date Sat, 28 Oct 2006 10:01:35 GMT

On 10/27/2006 09:41 PM, William A. Rowe, Jr. wrote:
> Graham Leggett wrote:
>>I see lots of comments on the code, but the comments are summarised as
>>"the cache is fine as it is". It isn't. If it was fine, key users of
>>network caching wouldn't be standing up saying they're using something
> I concur, but the history becomes a nightmare.  Let's back out the vetoed
> efforts and work up -clean- patches to apply that solve one issue each,
> and don't raise the objections again?

Apart from this, Paul created a branch a while ago for mod_cache refactoring.
As it has turned out the whole thing creates some bigger discussion and patches
go in and out. So I think it would be a good idea to do this on a dev branch instead
of the trunk. So I propose the following thing:

1. Create a dev branch again for mod_cache based on the current trunk.
2. Rollback the patches on trunk
3. Work out the whole thing on the dev branch until there is consensus about
   the solution and only minor issues need to be addressed.
4. Merge the dev branch back into trunk.
5. Address the minor issues on trunk and tweak it there.

This gives people who cannot follow up the whole history the chance to review
the whole thing on step 4. as some sort of reviewing a complete new module :-)

Furthermore it might be helpful to start the discussion Paul suggested before.

The patches from Niklas have been around for a while and there had been some discussions
about them before but not much happened before Graham started to commit them. I must
admit for myself that I did not have a very close look to these patches before due
to time constraints but Graham's commits "forced" me to have a closer look on it and to
shift some priorites. So I think his commits had been very helpful to get momentum in
this topic and I would expect that this momentum can be kept even if we go for a dev
branch and have some "non commit mail" discussion in advance as Paul suggested.

As I see some frustration in some of the recent mails from Niklas and Graham:

Although I do not agree with every technical aspect of the patches and agree with
some of the critical remarks, a big thanks to both (and to Davi of course) for being
persistent on this topic and move things forward.



View raw message