Ruediger Pluem wrote:
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 :-)
A trunk by any other name, will still smell as sweet.If the branch was created beforehand, then this would have made sense, but to have created the branch so late in the process, we are just creating work for ourselves that will ultimately end up with the same result.
Currently history reflects the reality of what was tried along the road, what was objected to, backed out, and tried again.
If we redo this without the objected-to bits, we are simply rewriting history (literally), thus removing the history's real value.
Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
