You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ian Holsman <ia...@apache.org> on 2002/05/29 19:56:53 UTC
a cache removal policy for mod_mem_cache
I'm not commiting this until .37 is out the door
but I thought some people may be interested in this beforehand
http://webperf.org/a2/v37/cache
4 new files (cache_cache.[ch] | cache_pqueue.[ch] )
and some minor mods on mod_cache.c/h
the interesting mods are in mod_mem_cache
---Ian
Re: Tagging releases
Posted by Martin Kraemer <Ma...@Fujitsu-Siemens.com>.
On Wed, May 29, 2002 at 11:20:43PM +0200, Kraemer, Martin wrote:
...
I forgot to mention that, with Subversion, it's going to be completely
different again.
Martin
--
<Ma...@Fujitsu-Siemens.com> | Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
Re: Tagging releases
Posted by Cliff Woolley <jw...@virginia.edu>.
On Wed, 29 May 2002, Martin Kraemer wrote:
> On Wed, May 29, 2002 at 02:40:12PM -0400, Cliff Woolley wrote:
>
> In the good old days, a tag was a tag was a tag. There was no "preliminary
> tag" which would then be moved to a different revision later on an
> ad-hoc basis.
I never said it would be moved. I said ANOTHER tag would be done. Right
now we have JCW_PRE_2037. Next we'll have JCW_PRE2_2037, then
JCW_PRE3_2037. It's just a matter of release candidates in a way.
Roy was very insistent upon this when we were in the 2.0.36 release cycle
(and I agreed), but for 2.0.36 it was too late, we'd already bumped some
tags.
We agreed that from then on, some pre-tag would be done and we'd use
multiple tags to specify subsequent candidates. When one of those is
selected for release, it gets retagged as APACHE_2_0_xxx. We could just
spew through version numbers and maybe the next version released after
2.0.36 is 2.0.48, but that doesn't make much sense from the users'
perspective.
> a) a CVS tag is *NEVER* moved.
That has already been agreed upon AFAIK.
> b) a Release tag is always created as a _branch_ tag first.
> (The tag name could be APACHE_2_0_47_Branch or similar)
> % cvs co httpd-2.0
> % cd httpd-2.0
> % cvs tag -b APACHE_2_0_47_Branch
> % cvs up -r APACHE_2_0_47_Branch
-1. Please let's not go down the branch route. Merging sucks. We've
agreed time and time again that we don't want to use CVS branches.
> e) when the tar ball has been built _and announced_, then a final release
> tag is set on the release _Revision_ (cvs tag without "-b")
> % cvs tag APACHE_2_0_47
> Such a tag can not be moved later.
Except for the branch part, that has also already been agreed upon.
> f) If another release should be necessary (without going to the next
> Apache version for some reason), another name is tagged _on_the_branch_:
> % cvs ci securityfix.c
> % cvs tag APACHE_2_0_47_SecurityFix1
We have a hard enough time getting releases out, much less patchlevels.
--Cliff
Tagging releases
Posted by Martin Kraemer <Ma...@Fujitsu-Siemens.com>.
On Wed, May 29, 2002 at 02:40:12PM -0400, Cliff Woolley wrote:
>
> If you're going to commit it, just do it. That's what my preliminary tag
> was for... so I had a base from which to selectively include patches.
> When tagged, APACHE_2_0_37 will != HEAD. :)
In the good old days, a tag was a tag was a tag. There was no "preliminary
tag" which would then be moved to a different revision later on an
ad-hoc basis.
The way the httpd-2.0 releases work now are IMHO not very professional
from a release management perspective, and users (on dev@) are easily
confused by what's going on.
I hereby propose:
a) a CVS tag is *NEVER* moved.
b) a Release tag is always created as a _branch_ tag first.
(The tag name could be APACHE_2_0_47_Branch or similar)
% cvs co httpd-2.0
% cd httpd-2.0
% cvs tag -b APACHE_2_0_47_Branch
% cvs up -r APACHE_2_0_47_Branch
c) Such a Release Branch Tag is therefore *atomic* relative to the
Working Tree of the person who is tagging. Even if somebody commits
in the very same moment of the Branch-Tagging, the tag is still set
on whatever the person tagging had checked out.
d) if fixes need to be made against such a Release Branch, then they are
simply committed (on the branch).
% cvs ci blurb.c
But only a fraction of the changes made after tagging is relevant
to fixing the Release. Only these fixes should be applied to the
Branch. Or, if a fix is made on the branch first, it must also
be applied to HEAD manually.
e) when the tar ball has been built _and announced_, then a final release
tag is set on the release _Revision_ (cvs tag without "-b")
% cvs tag APACHE_2_0_47
Such a tag can not be moved later.
f) If another release should be necessary (without going to the next
Apache version for some reason), another name is tagged _on_the_branch_:
% cvs ci securityfix.c
% cvs tag APACHE_2_0_47_SecurityFix1
(to be fleshed out in more detail if approved; especially tag naming)
The result is reproducibility (the tag names never move their place)
and easier collaboration (no more "no commits during the next 8 hrs please").
If people want "the 2.0.47" release, they checkout APACHE_2_0_47.
% cvs co -r APACHE_2_0_47 httpd-2.0
Such a copy cannot be used to commit changes (because a tag is a tag
is a tag, and there cannot be two different versions under one name)
If developers want to update the 2.0.47 (for developing and commiting
a hypothetical security fix1) they checkout the Branch version:
% cvs co -r APACHE_2_0_47_Branch httpd-2.0
Such a copy _can_ be modified, and changes can be committed.
In ASCII graphics it could look similar to the appended example.
What do you think about this proposal?
Martin
--------------------------------------
Head Branch 1
!
* 1.17
!\
! \
! \
! \ Branch 1.17.2 aka. "APACHE_2_0_47_Branch"
! \
! \
! \
! * 1.17.2.1 (fix against 1.17)
! !
* 1.18 !
! !
! * 1.17.2.2 (2nd fix)
! ! later tagged "APACHE_2_0_47" release tar ball
* 1.19 !
! * 1.17.2.3 (Security Fix applied)
! ! later tagged "APACHE_2_0_47_SecurityFix1" release tar ball
!
* 1.20 incorporating the fixes from the APACHE_2_0_47_Branch branch
!
HEAD
--
<Ma...@Fujitsu-Siemens.com> | Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
Re: a cache removal policy for mod_mem_cache
Posted by Cliff Woolley <jw...@virginia.edu>.
On Wed, 29 May 2002, Ian Holsman wrote:
> I'm not commiting this until .37 is out the door
> but I thought some people may be interested in this beforehand
>
> http://webperf.org/a2/v37/cache
If you're going to commit it, just do it. That's what my preliminary tag
was for... so I had a base from which to selectively include patches.
When tagged, APACHE_2_0_37 will != HEAD. :)
--Cliff