You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Justin Erenkrantz <je...@ebuilt.com> on 2001/08/30 05:22:24 UTC
2.0.26?
Should we be at 2.0.26-dev in ap_release.h? -- justin
Re: 2.0.26?
Posted by Jeff Trawick <tr...@attglobal.net>.
Cliff Woolley <cl...@yahoo.com> writes:
> On 30 Aug 2001, Jeff Trawick wrote:
>
> > Ian Holsman <Ia...@cnet.com> writes:
> >
> > > should we re-roll&tar 26 (which would include a patch to worker and
> > > ldap_cache, some NW fixes and the apr-dbm change)
> >
> > we might wanna wait to tag 2.0.26 until we get httpd not to leave
> > behind shared memory on Linux every time you start and stop it :)
>
> Okay. I wasn't aware of this problem. Does it look like there might
> possibly be an "easy" fix?
too early to tell...
more details:
prefork
level of code is pretty darn close to HEAD
the shared memory cleanup gets called in the parent and we do shmdt()
use count while running is 6 (parent + 5 servers)
use count after sending sigterm is 0
maybe at creation time we need to do something to have the shared
memory go away when the use count hits zero?
dunno... gotta go look at docs and read some code (like mm :) )
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: 2.0.26?
Posted by Cliff Woolley <cl...@yahoo.com>.
On 30 Aug 2001, Jeff Trawick wrote:
> > Okay. I wasn't aware of this problem. Does it look like there might
> > possibly be an "easy" fix?
>
> fixed now... just copied some ommitted code from mm
Sweet. Thanks. Tag time now planned for 6:30pm EDT (right now I'm late
for class)...
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: 2.0.26?
Posted by Jeff Trawick <tr...@attglobal.net>.
Cliff Woolley <cl...@yahoo.com> writes:
> On 30 Aug 2001, Jeff Trawick wrote:
>
> > Ian Holsman <Ia...@cnet.com> writes:
> >
> > > should we re-roll&tar 26 (which would include a patch to worker and
> > > ldap_cache, some NW fixes and the apr-dbm change)
> >
> > we might wanna wait to tag 2.0.26 until we get httpd not to leave
> > behind shared memory on Linux every time you start and stop it :)
>
> Okay. I wasn't aware of this problem. Does it look like there might
> possibly be an "easy" fix?
fixed now... just copied some ommitted code from mm
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: 2.0.26?
Posted by Cliff Woolley <cl...@yahoo.com>.
On 30 Aug 2001, Jeff Trawick wrote:
> Ian Holsman <Ia...@cnet.com> writes:
>
> > should we re-roll&tar 26 (which would include a patch to worker and
> > ldap_cache, some NW fixes and the apr-dbm change)
>
> we might wanna wait to tag 2.0.26 until we get httpd not to leave
> behind shared memory on Linux every time you start and stop it :)
Okay. I wasn't aware of this problem. Does it look like there might
possibly be an "easy" fix?
> (wow, the day goes by and I haven't even gotten to any tasks I'd
> planned on working on)
You just described my whole life lately... <sigh>
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: 2.0.26?
Posted by Jeff Trawick <tr...@attglobal.net>.
Ian Holsman <Ia...@cnet.com> writes:
> should we re-roll&tar 26 (which would include a patch to worker and
> ldap_cache, some NW fixes and the apr-dbm change)
we might wanna wait to tag 2.0.26 until we get httpd not to leave
behind shared memory on Linux every time you start and stop it :)
this helps, though
ipcs -m | grep 49160 | awk '{print $2}' | xargs -n 1 ipcrm shm
where 49160 is the size I'm currently getting for the scoreboard
(wow, the day goes by and I haven't even gotten to any tasks I'd
planned on working on)
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: 2.0.26?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
No docs change needed (see the previous note to the list.)
----- Original Message -----
From: "Justin Erenkrantz" <je...@ebuilt.com>
To: <de...@httpd.apache.org>
Sent: Wednesday, August 29, 2001 11:20 PM
Subject: Re: 2.0.26?
> On Wed, Aug 29, 2001 at 09:18:00PM -0700, Justin Erenkrantz wrote:
> > I'm verifying wrowe's commit right now. It looks right. =)
> > See if it works right...
>
> wrowe's commit took out SetHandler (on purpose??) which means that
> the server-status conf example needs to change. Trying to figure
> out what it should be. -- justin
>
>
Re: 2.0.26?
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Wed, Aug 29, 2001 at 09:18:00PM -0700, Justin Erenkrantz wrote:
> I'm verifying wrowe's commit right now. It looks right. =)
> See if it works right...
wrowe's commit took out SetHandler (on purpose??) which means that
the server-status conf example needs to change. Trying to figure
out what it should be. -- justin
Re: 2.0.26?
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Thu, Aug 30, 2001 at 11:09:34AM -0400, Cliff Woolley wrote:
> On Thu, 30 Aug 2001, Ryan Bloom wrote:
>
> > > > We shouldn't do either. If you go back and read the original thread,
> > > > one of the general rules of this release strategy is that we don't
> > > > release every day. We just rolled a tarball, and announced it to the
> > > > new-httpd, so there are people testing it at this point. That tarball
> > > > has to stand or fall on it's own. In a week, we can re-roll 2.0.26, and
> > > > try again.
>
> That's silly. That makes it very difficult to be sure we're stable again
> by the time we're "allowed" to tag 2.0.26. I agree wholeheartedly with
> whomever it was that said the only problem with our current system is the
> concatenation of the words "tag" and "roll" into a single "tag&roll"
> operation. We need to tag, test for just a little while to sort out the
> obvious problems that have just bitten 2.0.25, and THEN roll. Rolling
> before preliminary tests are done is silly. Half the time it means that
> we don't even build on some systems, which we could have found out about
> if we'd waited an hour to give people a chance to check. I agree with
> Bill that there needs to be a time limit on the duration between the tag
> and the roll... four days sounds good (if not excessive). That's what
> killed 2.0.23 and 2.0.24 in a way... they took too damned long. At least
> if we spread it out over a couple days, we don't twiddle our thumbs for a
> week after we realize that the tarball we just rolled is broken for some
> piddly-ass reason or another. Besides, if we wait a day or two between
> the tag and the roll, there would never BE a reason to release every day,
> so that problem just vanishes for free.
+1. Couldn't say it better myself. I would say a 48 hour window from
tag to roll would work out best. Doing a tag and a roll at the same
time isn't good. I think Roy's point was that the RM and the
development community should perform some sanity tests before rolling
it, but after tagging.
FWIW, John Sachs committed a test to httpd-test for the content-type of
a 404 message. So, if you use httpd-test, we won't get bit by this
same problem in the future. Any httpd committer already has access,
so they should feel free to add tests. (Do subscribe to
test-dev@httpd.apache.org though...) -- justin
Re: 2.0.26?
Posted by Ian Holsman <Ia...@cnet.com>.
[snip]
> tag and roll and test. If that one isn't good enough, then we do it again a week
> later. We would easily get to a beta or production release, if we didn't keep
> changing the internals of the server, or if we posted large patches before
> they were committed, or if people ran the httpd-test/perl-framework test suite
> before committing, and if people would write tests once they fix a bug. The
> problem we have right now, is that most people don't use the test-suite, so
> even though it is catching most of the bugs when they are committed, nobody
> knows it.
ok.
I'm going to set up the perl framework to run nightly at report the
errors it sees back to this list.
If this works properly my intention is to get it going after every
commit.
I can also get something like the mod-proxy nightly build as well.
>
> Ryan
>
> ______________________________________________________________
> Ryan Bloom rbb@apache.org
> Covalent Technologies rbb@covalent.net
> --------------------------------------------------------------
--
Ian Holsman
Performance Measurement & Analysis
CNET Networks - 415 364-8608
Re: 2.0.26?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Ryan Bloom" <rb...@covalent.net>
Sent: Thursday, August 30, 2001 8:57 AM
> On Thursday 30 August 2001 06:38, Bill Stoddard wrote:
> > Completely agree that our release strategy (with Dr. Evil quotes around
> > strategy) is broken. But we should be able to tag the tree anytime, IMHO.
> > If HEAD is good, I am for tagging 2.0.26 and testing it but let's not roll
> > the tarball. Fix any problems in 2.0.26 and bump the tag on affected files.
> > When we are satisfied, roll 2.0.26. Put a time limit on the whole process
> > of say, 4 days. If the time limit is exceeded (showstopper problems have
> > not been driven out within 4 days of the tag) or the rolled tarball has
> > showstoppers, consider the beta effort a failure and move on.
I'd say scope, over time. If two platforms are 'touchy' about the build, and there
is a three line patch to get those to build, then we do it. If there is a segfault
we can close (say J. Trawick's fix of my oops last night) then we close it.
I'm going to suggest a simple, absolute rule. If a .h file changes (even a generated
one) then the tag is deep six-ed. If the httpd-std.conf file changes, it's axed.
And if the syntax parsers change, it's axed. Anything in between is our call.
I'm going to suggest we branch every release as APACHE_2_0_nn once we apply any patch
out-of-sequence (from HEAD). E.g., I commit a feature after HTTP_2_0_30 is tagged.
Then someone notices a rare segfault dating to 2.0.12. Well, That patch goes in, but
if it needs to be dropped on HTTP_2_0_30, then we branch with the original APACHE_2_0_nn
tag. Anyone who checks out from cvs co -r APACHE_2_0_nn has the authoritative, current
candidate.
And I suggest we go to r-t-c on following any tag. I'm not suggesting r-t-c on the
main branch, since there aren't enough people following some obscure aspects of the
server to comment (in a timely manner.) But once it's tagged - 3 +1's before patching
(or even bumping) a tag!
> > This is basically what we did with 2.0.24 and it was almost successful.
> > 2.0.24 dragged on a bit too long (over a week) and we rolled a couple of
> > different 2.0.24 tarballs, which was not cool. Tagging a good HEAD,
> > incrementally fixing showstoppers (provided the fixes are relatively
> > limited in scope and simple) and bumping the tag on affected files, and
> > exercising a little disipline and restraint for a few days (even just a few
> > hours) prior to our target for rolling a beta would go a long way to
> > solving this problem.
>
> And it would go a long way towards pissing off our testers. We have people
> who download the tarball when we release it, and if we replace that tarball
> after just a few hours, then we are basically telling them that we don't need
> their input, and they are only useful if they actually follow new-httpd, which
> I think we all know is INCREDIBLY hard to do most days.
Ryan, how many testers lists do we have? dev@httpd is _NOT_ the tarball test list.
The order must go
1. Tag. Announce as version candidate at dev@httpd.apache.org.
2. wait for folks to build and regress (24 hours???)
3. vote. Is the feedback [at least] alpha quality? Are there no beta showstoppers?
4. bump subrevision to -alpha [optional - but I think we need to go here]
5. Tar. Announce as beta candidate at current-testers@apache.org
6. wait for folks to build, regress, and stress (72 hours???)
7. vote. Is the feedback [at least] beta quality? Are there no release showstoppers?
8. bump subrevision to -beta [optional - but I think we need to go here]
9. Tar. Announce as release candidate at stable-testers@apache.org
10. wait for folks to build, regress, and further stress (one week???).
11. The Adventuous may experiment with installing to production on non-critical servers.
12. vote. Is the feedback of release quality? Are there no new showstoppers?
14. bump subrevision to -gold.
15. Tar. Up to www.apache.org/dist/. Broadcast the release
There will be no changes to a -gold release, ever. We could subversion the -alpha and
-beta versions, e.g. 2.0.25.nnnn-alpha. I propose the number of days since the official
release of Apache 1.0 ;)
Take a page from the Jakarta project - their release schema works.
> tag and roll and test. If that one isn't good enough, then we do it again a week
> later. We would easily get to a beta or production release, if we didn't keep
> changing the internals of the server, or if we posted large patches before
> they were committed, or if people ran the httpd-test/perl-framework test suite
> before committing, and if people would write tests once they fix a bug. The
> problem we have right now, is that most people don't use the test-suite, so
> even though it is catching most of the bugs when they are committed, nobody
> knows it.
Since apxs is so totally borked that it cannot run on httpd-2.0/win32 (unlike apache-1.3)
that is mildly difficult in some quarters. I've specifically introduced the cygwin support
to allow me to build httpd-test. We will see how this goes.
Bill
Re: 2.0.26?
Posted by Bill Stoddard <bi...@wstoddard.com>.
> From: "Bill Stoddard" <bi...@wstoddard.com>
> Sent: Thursday, August 30, 2001 11:55 AM
>
>
> > Not really. The process Cliff and I outlined is really aimed at getting -a- stable
release
> > available. The process will take at least 2 days to go through but shouldn't take more
> > than maybe 4 days total. If we use this process AND use your suggestions to not commit
> > huge chunks of untested code during our 'stabilization period' I am confident we can
get
> > stable releases out on almost every try. We can control the release of tarballs to the
> > test community.
> >
> > And what is the point of having testers spend time on a release that we know is
broken?
> > Isn't it better to just tell them "hey don't waste your time on this tarball"?.
OTOH...
> > what rule says that testers must test each and every tarball? If a tarball (even an
alpha
> > tarball) works well enough, the testers can still find and report bugs that we havent
> > discovered yet.
> >
> > One other question... have you received complaints from testers about the frequencey
of
> > our tarball updates?
>
> Keep in mind one key detail, our most _active_ testers are using cvs (even on win32 ;)
>
>
>
> > I don't think we are currently using the model suggested by Roy. I believe Roy's model
is
> > closer to what Cliff and I are advocating. With one exception... The exception is that
> > some of us believe a 'feature freeze' (or 'big code change freeze', whatever you want
to
> > call it) needs to go into effect during the 'stabilizing period'. I know Roy doesn't
like
> > this idea but I see no other way out of our current inability to get stable releases.
>
> There is no such need. Tag. Roll in or out the changes that get a particular version
> stable. We have CVS. Use it.
>
>
>
> > > Yep. :-) But we also need to stop committing every possible change immediately.
> >
> > +1. Announce when we are in the 'stabilization period' and discourage (prohibit? :-)
big
> > commits during the period that do not enhance stability.
>
> My other post suggests we simply follow R-T-C (with a strict 3 +1's except on obscure
> build maintenance by platform maintainers) on a tagged branch. There's no need for this
> in the main tree.
>
> See my post to rbb for the rest of my thoughts on this personal slight,
> you are certainly impliciated as well.
>
No slight intended, personal or otherwise. Big code drops going in right as we announce a
tag & roll is normal. It happens -every- time and most of us have been the perps at one
time or another. This is pretty normal in closed source development shops as well when
trying to hit driver dates. Everybody has code that -must- go in or the release will just
be totally hosed (in their mind :-).
We clearly have a problem getting stable releases out and I'm interested in solving the
problem, not pointing fingers.
Bill
Re: 2.0.26?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Bill Stoddard" <bi...@wstoddard.com>
Sent: Thursday, August 30, 2001 11:55 AM
> Not really. The process Cliff and I outlined is really aimed at getting -a- stable release
> available. The process will take at least 2 days to go through but shouldn't take more
> than maybe 4 days total. If we use this process AND use your suggestions to not commit
> huge chunks of untested code during our 'stabilization period' I am confident we can get
> stable releases out on almost every try. We can control the release of tarballs to the
> test community.
>
> And what is the point of having testers spend time on a release that we know is broken?
> Isn't it better to just tell them "hey don't waste your time on this tarball"?. OTOH...
> what rule says that testers must test each and every tarball? If a tarball (even an alpha
> tarball) works well enough, the testers can still find and report bugs that we havent
> discovered yet.
>
> One other question... have you received complaints from testers about the frequencey of
> our tarball updates?
Keep in mind one key detail, our most _active_ testers are using cvs (even on win32 ;)
> I don't think we are currently using the model suggested by Roy. I believe Roy's model is
> closer to what Cliff and I are advocating. With one exception... The exception is that
> some of us believe a 'feature freeze' (or 'big code change freeze', whatever you want to
> call it) needs to go into effect during the 'stabilizing period'. I know Roy doesn't like
> this idea but I see no other way out of our current inability to get stable releases.
There is no such need. Tag. Roll in or out the changes that get a particular version
stable. We have CVS. Use it.
> > Yep. :-) But we also need to stop committing every possible change immediately.
>
> +1. Announce when we are in the 'stabilization period' and discourage (prohibit? :-) big
> commits during the period that do not enhance stability.
My other post suggests we simply follow R-T-C (with a strict 3 +1's except on obscure
build maintenance by platform maintainers) on a tagged branch. There's no need for this
in the main tree.
See my post to rbb for the rest of my thoughts on this personal slight,
you are certainly impliciated as well.
Bill
Re: 2.0.26?
Posted by Cliff Woolley <cl...@yahoo.com>.
On Thu, 30 Aug 2001, Roy T. Fielding wrote:
> The only BIG problem I had with Cliff's process of retagging individual
> files is that by the time he and OtherBill were finished I had no clue
> what was in the actual release version.
I can see where that would be a problem.
> How about if we go to the suggestion I posted at the time? Tag what is
> believed to be good as APACHE_GOOD, have people check that out as a branch
> and bring it up to snuff on platforms as needed, then bump the version and
> retag the APACHE_GOOD revisions as APACHE_2_0_XX, and finally merge that
> version back into HEAD. That way HEAD can keep going without bounds and
> the folks who need a polished release without the latest big fixes can
> focus their efforts on the mini-branch.
Okay, that's a reasonable approach. I didn't see the point last time, but
now I do. +1. I'll do it that way this time.
> Personally, as much as I dislike the current lack of a release tarball,
> I am more pleased with the rate at which *significant* problems are being
> found and fixed in 2.0. In my opinion, the reason 2.0 doesn't have a good
> beta release is because it simply has not been ready for beta release -- the
> big fixes we have been making lately have vastly improved it over what
> it was two months ago.
That's a good point, one we shouldn't forget. :)
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: 2.0.26?
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> Not really. The process Cliff and I outlined is really aimed at getting -a- stable release
> available. The process will take at least 2 days to go through but shouldn't take more
> than maybe 4 days total. If we use this process AND use your suggestions to not commit
> huge chunks of untested code during our 'stabilization period' I am confident we can get
> stable releases out on almost every try. We can control the release of tarballs to the
> test community.
The only BIG problem I had with Cliff's process of retagging individual
files is that by the time he and OtherBill were finished I had no clue
what was in the actual release version.
How about if we go to the suggestion I posted at the time? Tag what is
believed to be good as APACHE_GOOD, have people check that out as a branch
and bring it up to snuff on platforms as needed, then bump the version and
retag the APACHE_GOOD revisions as APACHE_2_0_XX, and finally merge that
version back into HEAD. That way HEAD can keep going without bounds and
the folks who need a polished release without the latest big fixes can
focus their efforts on the mini-branch.
Personally, as much as I dislike the current lack of a release tarball,
I am more pleased with the rate at which *significant* problems are being
found and fixed in 2.0. In my opinion, the reason 2.0 doesn't have a good
beta release is because it simply has not been ready for beta release -- the
big fixes we have been making lately have vastly improved it over what
it was two months ago.
....Roy
Re: 2.0.26?
Posted by Bill Stoddard <bi...@wstoddard.com>.
> On Thursday 30 August 2001 08:09, Cliff Woolley wrote:
> > On Thu, 30 Aug 2001, Ryan Bloom wrote:
> > > > > We shouldn't do either. If you go back and read the original thread,
> > > > > one of the general rules of this release strategy is that we don't
> > > > > release every day. We just rolled a tarball, and announced it to the
> > > > > new-httpd, so there are people testing it at this point. That
> > > > > tarball has to stand or fall on it's own. In a week, we can re-roll
> > > > > 2.0.26, and try again.
> >
> > That's silly. That makes it very difficult to be sure we're stable again
> > by the time we're "allowed" to tag 2.0.26. I agree wholeheartedly with
> > whomever it was that said the only problem with our current system is the
> > concatenation of the words "tag" and "roll" into a single "tag&roll"
> > operation. We need to tag, test for just a little while to sort out the
> > obvious problems that have just bitten 2.0.25, and THEN roll. Rolling
>
> That doesn't work. The last time I tagged, and then waited to roll, I was
> told that I needed to get tarballs up so that people could download them.
Well, I was one of those people that requested you roll a tarball and that was a mistake.
It is simple enough to do a tagged cvs update. We do not need to provide tarballs
immediately after we tag.
>
> > before preliminary tests are done is silly. Half the time it means that
> > we don't even build on some systems, which we could have found out about
> > if we'd waited an hour to give people a chance to check. I agree with
>
> Waiting an hour doesn't do anything. Most people on this list don't hack
> Apache all day every day. The whole point of the current system, is that
> we tag when things all look good. If we are wrong, then we wait a week,
> and try again.
Are we really discussing the time between tag and roll now? If an hour is not enough,
then make it a day or three. I suspect however the time between tag and roll is really not
the issue for you. Gotta convince you that the whole notion of tagging anytime and
defering the roll for n amt of time is a good process :-) I think it is. Once you've
bought in, then we can discuss implementation details.
>
> > Bill that there needs to be a time limit on the duration between the tag
> > and the roll... four days sounds good (if not excessive). That's what
> > killed 2.0.23 and 2.0.24 in a way... they took too damned long. At least
> > if we spread it out over a couple days, we don't twiddle our thumbs for a
> > week after we realize that the tarball we just rolled is broken for some
> > piddly-ass reason or another. Besides, if we wait a day or two between
> > the tag and the roll, there would never BE a reason to release every day,
> > so that problem just vanishes for free.
>
> You are still asking testers to test multiple versions.
Not really. The process Cliff and I outlined is really aimed at getting -a- stable release
available. The process will take at least 2 days to go through but shouldn't take more
than maybe 4 days total. If we use this process AND use your suggestions to not commit
huge chunks of untested code during our 'stabilization period' I am confident we can get
stable releases out on almost every try. We can control the release of tarballs to the
test community.
And what is the point of having testers spend time on a release that we know is broken?
Isn't it better to just tell them "hey don't waste your time on this tarball"?. OTOH...
what rule says that testers must test each and every tarball? If a tarball (even an alpha
tarball) works well enough, the testers can still find and report bugs that we havent
discovered yet.
One other question... have you received complaints from testers about the frequencey of
our tarball updates?
> Or, you are going back
> to the 1.3 model, where we hit a code-freeze, so every developer out there
> commits everything they have in their tree just before we go code-freeze.
> That is the problem that killed Apache 1.3.13, 14, 15, 16.
>
> > > And it would go a long way towards pissing off our testers. We have
> > > people who download the tarball when we release it, and if we replace
> > > that tarball after just a few hours,
> >
> > Whoa... time out. I'm saying (and I think Bill is, too), that we *do not*
> > replace the tarball. Once it's rolled, that's it. If the tarball's
> > broken, try again with a new tag later. We can easily test it for obvious
> > flaws ourselves between the tag and the roll. Once *we're* satisfied,
> > roll it and give it to the testers. If they're satisfied, release.
> >
> > That's what we did on 2.0.22 and 2.0.23, and they very nearly made it.
> > 2.0.24 took the re-roll-a-thousand-times approach as an approximation of
> > the method, and it was also close (though I seriously dislike the
> > re-rolling part). But if we think that just snapshotting the tree and
> > then doing it again a week later is sufficient to ever get a server that's
> > release-quality, we're kidding ourselves IMO.
>
> You know what's funny? When Roy suggested this model, that was the
> exact argument I used to explain why it wouldn't work. That is the
> release model we decided to use though.
I don't think we are currently using the model suggested by Roy. I believe Roy's model is
closer to what Cliff and I are advocating. With one exception... The exception is that
some of us believe a 'feature freeze' (or 'big code change freeze', whatever you want to
call it) needs to go into effect during the 'stabilizing period'. I know Roy doesn't like
this idea but I see no other way out of our current inability to get stable releases.
> The point is, the developers
> know best when the tree is good. So, the developers tag it when they
> think it is good. If we as the programmers can't determine when the
> tree is good, then we have some pretty big problems.
>
> > > We would easily get to a beta or production release, if we didn't keep
> > > changing the internals of the server, or if we posted large patches
> > > before they were committed, or if people ran the
> > > httpd-test/perl-framework test suite before committing, and if people
> > > would write tests once they fix a bug. The problem we have right now,
> > > is that most people don't use the test-suite, so even though it is
> > > catching most of the bugs when they are committed, nobody knows it.
> >
> > At least on this front, I'm in total agreement... the httpd-test suite is
> > excellent. I've gotten to where I rely on it heavily to test any change I
> > make (even small ones) before committing, because it's so good at sniffing
> > out the subtle (and not-so-subtle) problems. If everybody used it, we'd
> > be set.
>
> Yep. :-) But we also need to stop committing every possible change immediately.
+1. Announce when we are in the 'stabilization period' and discourage (prohibit? :-) big
commits during the period that do not enhance stability.
Bill
Re: 2.0.26?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Bill Stoddard" <bi...@wstoddard.com>
Sent: Thursday, August 30, 2001 2:17 PM
> > Certainly converting mod_mime
> > to a hash makes the other key whiner of "we've got to get this out the door" look
> > equally foolish. That patch ate a week of several people's lives. I hope the
> > performance improvement proves worth it.
>
> Heh, heh. You already know the answer to that question. If there are still problems with
> the hash, I would vote to revert back to tables. A little performance boost is nice but
> not at the expense of reasonable simplicity.
Problems? Of course not (anymore). Of course nobody but Brian Pane has commented on the
optimization schema to avoid merges of all sorts without introducing conf->pool corruption.
Message-ID: <00...@roweclan.net>
From: "William A. Rowe, Jr." <wr...@rowe-clan.net>
To: <ne...@apache.org>
Subject: Optimizing dir_merge()
Date: Wed, 15 Aug 2001 19:28:31 -0500
and it's suppliment
Message-ID: <02...@roweclan.net>
From: "William A. Rowe, Jr." <wr...@rowe-clan.net>
To: <ne...@apache.org>
References: <00...@roweclan.net> <3B...@pacbell.net>
Subject: Re: Optimizing dir_merge()
Date: Wed, 15 Aug 2001 20:36:08 -0500
this schema helps any module be a good citizen in Apache performance, if we adopt these
guidelines. The entire server should pick up a good bit.
Bill - want a fun one line patch? Go find the expand hash fn, and change the hash
size growth from (last_element * 2 + 1) to ((last_element + 1) * 4 - 1)
Re: 2.0.26?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Brian Pane" <bp...@pacbell.net>
Sent: Thursday, August 30, 2001 3:09 PM
> What's not clear, however, is how much of a speedup we're getting from all
> the subsequent enhancements to avoid copying in the same-pool case (which is
> where all the real complexity is). Anybody have benchmark or profile data
> on this part?
We still copy in this case. You would need to experiment, per the short writeup
I did, by modifying any module that does a table_merge or table_overlap or some
hash merge. If you could post such numbers, perhaps that would get some further
scrutiny from members of the list.
Bill
Re: 2.0.26?
Posted by Brian Pane <bp...@pacbell.net>.
Bill Stoddard wrote:
>>Certainly converting mod_mime
>>to a hash makes the other key whiner of "we've got to get this out the door" look
>>equally foolish. That patch ate a week of several people's lives. I hope the
>>performance improvement proves worth it.
>>
The hashes themselves seem to be an improvement. Previously, apr_table_get
was a hotspot in performance profiles, and now it isn't any more.
What's not clear, however, is how much of a speedup we're getting from all
the subsequent enhancements to avoid copying in the same-pool case (which is
where all the real complexity is). Anybody have benchmark or profile data
on this part?
--Brian
Re: 2.0.26?
Posted by Bill Stoddard <bi...@wstoddard.com>.
> Certainly converting mod_mime
> to a hash makes the other key whiner of "we've got to get this out the door" look
> equally foolish. That patch ate a week of several people's lives. I hope the
> performance improvement proves worth it.
Heh, heh. You already know the answer to that question. If there are still problems with
the hash, I would vote to revert back to tables. A little performance boost is nice but
not at the expense of reasonable simplicity.
Bill
Re: 2.0.26?
Posted by Ryan Bloom <rb...@covalent.net>.
> > > > We would easily get to a beta or production release, if we didn't
> > > > keep changing the internals of the server, or if we posted large
> > > > patches before they were committed, or if people ran the
> > > > httpd-test/perl-framework test suite before committing, and if people
> > > > would write tests once they fix a bug. The problem we have right
> > > > now, is that most people don't use the test-suite, so even though it
> > > > is catching most of the bugs when they are committed, nobody knows
> > > > it.
> > >
> > > At least on this front, I'm in total agreement... the httpd-test suite
> > > is excellent. I've gotten to where I rely on it heavily to test any
> > > change I make (even small ones) before committing, because it's so good
> > > at sniffing out the subtle (and not-so-subtle) problems. If everybody
> > > used it, we'd be set.
>
> Since apxs is so totally borked that it cannot run on httpd-2.0/win32
> (unlike apache-1.3) that is mildly difficult in some quarters. I've
> specifically introduced the cygwin support to allow me to build httpd-test.
> We will see how this goes.
>
> > Yep. :-) But we also need to stop committing every possible change
> > immediately. I don't care about making changes to the server, but post
> > the patches to the list first, so that somebody can tag if it looks like
> > a large patch.
>
> Ahhh... er, so it's ignored? When was the last time you reviewed a
> non-thread, non-pool, non-mpm issue, Ryan?
Yeah, I admit it, I don't have the time these days to review every single
patch. I focus most of my time on APR, instead of the server, and the
worker MPM, because I believe that has a lot of potential. What's
your point? That because not everybody can review in under 1 day
they shouldn't be given the chance before the commit goes in?
> Folks are spending alot of time on their platforms, getting things right.
> They aren't reviewing one another's work. We are all guilty on this count.
>
> Further, we are in C-T-R mode the last time I noticed.
C-T-R does not mean that everything is C-T-R. It means that small
contained patches are C-T-R. Anything that rewrites a major portion of the
code is and always has been R-T-C.
> If you want patches before big commits, then fine, we tag
> pre_that_big_patch. If we agree, lower case tags can be dropped in, and
> pulled out, when convenient.
If people post before they commit, it gives everybody a chance to see what
is coming. Tagging before every big commit is overkill. Just be considerate
of the rest of the list, and post the big patches.
> That has nothing to do with the issue at hand. If you are addressing this
> to me, personally (as I believe you are) you may go blow it out your <>.
Actually, I am addressing this to the list in general. You happen to make the
biggest patches, and you happen to do so without posting them, but my feelings
are addressed to everybody. For major changes, please post before commit.
I may not review every single patch, but I will definately do my best to review
the major patches within a few days.
> The patches I've been commiting address fundemental flaws in the server
> architechture that have exposed over and over again holes in our negotation
> stratagy.
I didn't ever say they weren't good patches, just that they should have been
posted first, so that everybody could see what was coming, and prepare
accordingly.
> The fact that the filter model is non-existent for user
> configuration (and the fact that your original code blew up conf->pool)
> doesn't help either. These patches had to get in before the server would
> be worthy of 'beta' status anyways. Certainly converting mod_mime to a
> hash makes the other key whiner of "we've got to get this out the door"
> look equally foolish. That patch ate a week of several people's lives. I
> hope the performance improvement proves worth it.
Will, this was not a personal attack on you. I'm sorry if you think it was, it
wasn't. I honestly believe you have fixed more bugs in the last three weeks than
anybody else on list. I am just asking that if we are re-organizing how the
entire server handles URL's, then that should be reviewed before it is committed.
If somebody was going to re-write how the config file is read, I would ask for that
to be posted before commit. The filter stuff that you did, didn't need to be
posted first. There is a fine line, but it is there.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: 2.0.26?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "William A. Rowe, Jr." <wr...@rowe-clan.net>
Sent: Thursday, August 30, 2001 1:03 PM
> > > At least on this front, I'm in total agreement... the httpd-test suite is
> > > excellent. I've gotten to where I rely on it heavily to test any change I
> > > make (even small ones) before committing, because it's so good at sniffing
> > > out the subtle (and not-so-subtle) problems. If everybody used it, we'd
> > > be set.
>
> Since apxs is so totally borked that it cannot run on httpd-2.0/win32 (unlike apache-1.3)
> that is mildly difficult in some quarters. I've specifically introduced the cygwin support
> to allow me to build httpd-test. We will see how this goes.
Well, just so those of you on cygwin are aware, it seems that there is a bit more work
todo before cygwin will work with httpd-test (although it serves pages by simply commenting
out the user and group directives. I suspect that's the problem with the test framework,
as well.) I'm jumping over to Doug's suggestion to customize the code just a bit for win32
native, as long as I have to do the work. If anyone wants to play in cygwin, just check out
httpd-test from CVS, and go to town :)
> I'm asking key architechture questions to the list, and only about three of us are even
> participating in that discussion. As long as that's true, I don't expect a release
> this year unless I follow c-t-r to underlying opportunities for future exploits to appear.
^ ^
s/I/we/ fix the
if it wasn't obvious in spite the total lack of grammer, and this doesn't just go for me ;)
There are enough others working dilligently in their corners of the code to get those
parts right - code I certainly don't grok (nor expect to.) Thanks esp. Jeff, Ryan, Graham,
and the handful of others for touching new emits or breakage from my sometimes sloppy
incremental application of these patches. I'm doing what I can to move or touch one bit
at a time so the commits are more easily reviewed; my layering is sometimes hazerdous.
Re: 2.0.26?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Ryan Bloom" <rb...@covalent.net>
Sent: Thursday, August 30, 2001 11:04 AM
> On Thursday 30 August 2001 08:09, Cliff Woolley wrote:
> > On Thu, 30 Aug 2001, Ryan Bloom wrote:
> > > > > We shouldn't do either. If you go back and read the original thread,
> > > > > one of the general rules of this release strategy is that we don't
> > > > > release every day. We just rolled a tarball, and announced it to the
> > > > > new-httpd, so there are people testing it at this point. That
> > > > > tarball has to stand or fall on it's own. In a week, we can re-roll
> > > > > 2.0.26, and try again.
HuH? Ok, you rolled a tarball. Why? Our first-line testers are capable of
checking out cvs. Bump a tag (or branch), and a 30 second cvs checkout and
a < three minute make is all it takes to get testing.
> > That's silly. That makes it very difficult to be sure we're stable again
> > by the time we're "allowed" to tag 2.0.26. I agree wholeheartedly with
> > whomever it was that said the only problem with our current system is the
> > concatenation of the words "tag" and "roll" into a single "tag&roll"
> > operation. We need to tag, test for just a little while to sort out the
> > obvious problems that have just bitten 2.0.25, and THEN roll. Rolling
>
> That doesn't work. The last time I tagged, and then waited to roll, I was
> told that I needed to get tarballs up so that people could download them.
WTF? I don't remember seeing that discussion on the list. Since oh, about 2.0.21
we've been giving folks the opportunity to test. You are the only individual who
seems to be tarring as you tag these days.
> > before preliminary tests are done is silly. Half the time it means that
> > we don't even build on some systems, which we could have found out about
> > if we'd waited an hour to give people a chance to check. I agree with
>
> Waiting an hour doesn't do anything. Most people on this list don't hack
> Apache all day every day. The whole point of the current system, is that
> we tag when things all look good. If we are wrong, then we wait a week,
> and try again.
Not if you ever want to get anywhere. Tomcat has a good model - pay attention
to it - they get releases out the door.
> > Bill that there needs to be a time limit on the duration between the tag
> > and the roll... four days sounds good (if not excessive). That's what
> > killed 2.0.23 and 2.0.24 in a way... they took too damned long. At least
> > if we spread it out over a couple days, we don't twiddle our thumbs for a
> > week after we realize that the tarball we just rolled is broken for some
> > piddly-ass reason or another. Besides, if we wait a day or two between
> > the tag and the roll, there would never BE a reason to release every day,
> > so that problem just vanishes for free.
>
> You are still asking testers to test multiple versions. Or, you are going back
> to the 1.3 model, where we hit a code-freeze, so every developer out there
> commits everything they have in their tree just before we go code-freeze.
> That is the problem that killed Apache 1.3.13, 14, 15, 16.
And brought .14, .17, .19 and .20 out the door, as solid as we could expect them
to be under any release model. But 1.3 code is stable (if not always correct).
> > > And it would go a long way towards pissing off our testers. We have
> > > people who download the tarball when we release it, and if we replace
> > > that tarball after just a few hours,
Ryan, how many testers lists do we have? dev@httpd is _NOT_ the tarball test list.
The order must go
1. Tag. Announce as version candidate at dev@httpd.apache.org.
2. wait for folks to build and regress (24 hours???)
3. vote. Is the feedback [at least] alpha quality? Are there no beta showstoppers?
4. bump subrevision to -alpha [optional - but I think we need to go here]
5. Tar. Announce as beta candidate at current-testers@apache.org
6. wait for folks to build, regress, and stress (72 hours???)
7. vote. Is the feedback [at least] beta quality? Are there no release showstoppers?
8. bump subrevision to -beta [optional - but I think we need to go here]
9. Tar. Announce as release candidate at stable-testers@apache.org
10. wait for folks to build, regress, and further stress (one week???).
11. The Adventuous may experiment with installing to production on non-critical servers.
12. vote. Is the feedback of release quality? Are there no new showstoppers?
14. bump subrevision to -gold.
15. Tar. Up to www.apache.org/dist/. Broadcast the release
There will be no changes to a -gold release, ever. We could subversion the -alpha and
-beta versions, e.g. 2.0.25.nnnn-alpha. I propose the number of days since the official
release of Apache 1.0 ;)
> > Whoa... time out. I'm saying (and I think Bill is, too), that we *do not*
> > replace the tarball. Once it's rolled, that's it. If the tarball's
> > broken, try again with a new tag later. We can easily test it for obvious
> > flaws ourselves between the tag and the roll. Once *we're* satisfied,
> > roll it and give it to the testers. If they're satisfied, release.
That's what every other RM has done in the recent past. If it's not spelled out
in the release docs (rolling the tarball) then someone better write up our 'new'
procedures so it's clear to everyone, and we can vote on the changes going into
that release stratagy.
> > That's what we did on 2.0.22 and 2.0.23, and they very nearly made it.
> > 2.0.24 took the re-roll-a-thousand-times approach as an approximation of
> > the method, and it was also close (though I seriously dislike the
> > re-rolling part). But if we think that just snapshotting the tree and
> > then doing it again a week later is sufficient to ever get a server that's
> > release-quality, we're kidding ourselves IMO.
>
> You know what's funny? When Roy suggested this model, that was the
> exact argument I used to explain why it wouldn't work. That is the
> release model we decided to use though. The point is, the developers
> know best when the tree is good. So, the developers tag it when they
> think it is good. If we as the programmers can't determine when the
> tree is good, then we have some pretty big problems.
Of course we do. "Ask." Or tag, then ask. If the answer is "no" pull the tag,
and apply it when it's ready. If it's just one file that wasn't quite there,
bump the tag.
> > > We would easily get to a beta or production release, if we didn't keep
> > > changing the internals of the server, or if we posted large patches
> > > before they were committed, or if people ran the
> > > httpd-test/perl-framework test suite before committing, and if people
> > > would write tests once they fix a bug. The problem we have right now,
> > > is that most people don't use the test-suite, so even though it is
> > > catching most of the bugs when they are committed, nobody knows it.
> >
> > At least on this front, I'm in total agreement... the httpd-test suite is
> > excellent. I've gotten to where I rely on it heavily to test any change I
> > make (even small ones) before committing, because it's so good at sniffing
> > out the subtle (and not-so-subtle) problems. If everybody used it, we'd
> > be set.
Since apxs is so totally borked that it cannot run on httpd-2.0/win32 (unlike apache-1.3)
that is mildly difficult in some quarters. I've specifically introduced the cygwin support
to allow me to build httpd-test. We will see how this goes.
> Yep. :-) But we also need to stop committing every possible change immediately.
> I don't care about making changes to the server, but post the patches to
> the list first, so that somebody can tag if it looks like a large patch.
Ahhh... er, so it's ignored? When was the last time you reviewed a non-thread,
non-pool, non-mpm issue, Ryan?
Folks are spending alot of time on their platforms, getting things right. They aren't
reviewing one another's work. We are all guilty on this count.
Further, we are in C-T-R mode the last time I noticed.
If you want patches before big commits, then fine, we tag pre_that_big_patch. If we agree,
lower case tags can be dropped in, and pulled out, when convenient.
That has nothing to do with the issue at hand. If you are addressing this to me,
personally (as I believe you are) you may go blow it out your <>. The patches I've
been commiting address fundemental flaws in the server architechture that have
exposed over and over again holes in our negotation stratagy. The fact that the
filter model is non-existent for user configuration (and the fact that your original
code blew up conf->pool) doesn't help either. These patches had to get in before
the server would be worthy of 'beta' status anyways. Certainly converting mod_mime
to a hash makes the other key whiner of "we've got to get this out the door" look
equally foolish. That patch ate a week of several people's lives. I hope the
performance improvement proves worth it.
The mod_mime fiasco proves that nobody has built with APR_POOL_DEBUG in quite some
time. Try it, you discover lots of useful things about mis-merge and mis-configuration.
I've had a patch out there for, what, four weeks now to add a string to the apr_pool_create
function with the filename and line? Nobody reviewed, nobody commented. And if nobody
is reviewing our debugging code, then who's reviewing mainline code?
Had you personally taken the time to review recent patches, perhaps you would have known
the server wasn't ready to tag at that moment.
I'm asking key architechture questions to the list, and only about three of us are even
participating in that discussion. As long as that's true, I don't expect a release
this year unless I follow c-t-r to underlying opportunities for future exploits to appear.
Bill
Re: 2.0.26?
Posted by Ryan Bloom <rb...@covalent.net>.
On Thursday 30 August 2001 08:09, Cliff Woolley wrote:
> On Thu, 30 Aug 2001, Ryan Bloom wrote:
> > > > We shouldn't do either. If you go back and read the original thread,
> > > > one of the general rules of this release strategy is that we don't
> > > > release every day. We just rolled a tarball, and announced it to the
> > > > new-httpd, so there are people testing it at this point. That
> > > > tarball has to stand or fall on it's own. In a week, we can re-roll
> > > > 2.0.26, and try again.
>
> That's silly. That makes it very difficult to be sure we're stable again
> by the time we're "allowed" to tag 2.0.26. I agree wholeheartedly with
> whomever it was that said the only problem with our current system is the
> concatenation of the words "tag" and "roll" into a single "tag&roll"
> operation. We need to tag, test for just a little while to sort out the
> obvious problems that have just bitten 2.0.25, and THEN roll. Rolling
That doesn't work. The last time I tagged, and then waited to roll, I was
told that I needed to get tarballs up so that people could download them.
> before preliminary tests are done is silly. Half the time it means that
> we don't even build on some systems, which we could have found out about
> if we'd waited an hour to give people a chance to check. I agree with
Waiting an hour doesn't do anything. Most people on this list don't hack
Apache all day every day. The whole point of the current system, is that
we tag when things all look good. If we are wrong, then we wait a week,
and try again.
> Bill that there needs to be a time limit on the duration between the tag
> and the roll... four days sounds good (if not excessive). That's what
> killed 2.0.23 and 2.0.24 in a way... they took too damned long. At least
> if we spread it out over a couple days, we don't twiddle our thumbs for a
> week after we realize that the tarball we just rolled is broken for some
> piddly-ass reason or another. Besides, if we wait a day or two between
> the tag and the roll, there would never BE a reason to release every day,
> so that problem just vanishes for free.
You are still asking testers to test multiple versions. Or, you are going back
to the 1.3 model, where we hit a code-freeze, so every developer out there
commits everything they have in their tree just before we go code-freeze.
That is the problem that killed Apache 1.3.13, 14, 15, 16.
> > And it would go a long way towards pissing off our testers. We have
> > people who download the tarball when we release it, and if we replace
> > that tarball after just a few hours,
>
> Whoa... time out. I'm saying (and I think Bill is, too), that we *do not*
> replace the tarball. Once it's rolled, that's it. If the tarball's
> broken, try again with a new tag later. We can easily test it for obvious
> flaws ourselves between the tag and the roll. Once *we're* satisfied,
> roll it and give it to the testers. If they're satisfied, release.
>
> That's what we did on 2.0.22 and 2.0.23, and they very nearly made it.
> 2.0.24 took the re-roll-a-thousand-times approach as an approximation of
> the method, and it was also close (though I seriously dislike the
> re-rolling part). But if we think that just snapshotting the tree and
> then doing it again a week later is sufficient to ever get a server that's
> release-quality, we're kidding ourselves IMO.
You know what's funny? When Roy suggested this model, that was the
exact argument I used to explain why it wouldn't work. That is the
release model we decided to use though. The point is, the developers
know best when the tree is good. So, the developers tag it when they
think it is good. If we as the programmers can't determine when the
tree is good, then we have some pretty big problems.
> > We would easily get to a beta or production release, if we didn't keep
> > changing the internals of the server, or if we posted large patches
> > before they were committed, or if people ran the
> > httpd-test/perl-framework test suite before committing, and if people
> > would write tests once they fix a bug. The problem we have right now,
> > is that most people don't use the test-suite, so even though it is
> > catching most of the bugs when they are committed, nobody knows it.
>
> At least on this front, I'm in total agreement... the httpd-test suite is
> excellent. I've gotten to where I rely on it heavily to test any change I
> make (even small ones) before committing, because it's so good at sniffing
> out the subtle (and not-so-subtle) problems. If everybody used it, we'd
> be set.
Yep. :-) But we also need to stop committing every possible change immediately.
I don't care about making changes to the server, but post the patches to
the list first, so that somebody can tag if it looks like a large patch.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: 2.0.26?
Posted by Doug MacEachern <do...@covalent.net>.
On Thu, 30 Aug 2001, William A. Rowe, Jr. wrote:
> Looks like an excellent, well thought ought testbench. Shame it doesn't
> run everywhere.
we're just waiting for somebody to port it to the platforms it doesn't
currently run on :) the kit is based on modperl-1.x's "make test" which
runs on win32. see modperl-1.x/TEST.win32, uses Win32::Process to
start/stop the server. would be grand to have the 1.x win32 logic ported
to the new kit.
Re: 2.0.26?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Cliff Woolley" <cl...@yahoo.com>
Sent: Thursday, August 30, 2001 10:09 AM
> At least on this front, I'm in total agreement... the httpd-test suite is
> excellent. I've gotten to where I rely on it heavily to test any change I
> make (even small ones) before committing, because it's so good at sniffing
> out the subtle (and not-so-subtle) problems. If everybody used it, we'd
> be set.
Looks like an excellent, well thought ought testbench. Shame it doesn't run everywhere.
If stipe's patches 'take' then we are moving forward. Of course it cannot test the
native win32 mpm on windows today, only prefork on cygwin. But if that's a start,
I'll be satisfied.
BTW - I'm committing Stipe's patch to disable threads (well, double checking that
it's the correct patch) since many aspects of threading and foo_r detection are
broken on cygwin.
Bill
Re: 2.0.26?
Posted by Cliff Woolley <cl...@yahoo.com>.
On Thu, 30 Aug 2001, Ryan Bloom wrote:
> > > We shouldn't do either. If you go back and read the original thread,
> > > one of the general rules of this release strategy is that we don't
> > > release every day. We just rolled a tarball, and announced it to the
> > > new-httpd, so there are people testing it at this point. That tarball
> > > has to stand or fall on it's own. In a week, we can re-roll 2.0.26, and
> > > try again.
That's silly. That makes it very difficult to be sure we're stable again
by the time we're "allowed" to tag 2.0.26. I agree wholeheartedly with
whomever it was that said the only problem with our current system is the
concatenation of the words "tag" and "roll" into a single "tag&roll"
operation. We need to tag, test for just a little while to sort out the
obvious problems that have just bitten 2.0.25, and THEN roll. Rolling
before preliminary tests are done is silly. Half the time it means that
we don't even build on some systems, which we could have found out about
if we'd waited an hour to give people a chance to check. I agree with
Bill that there needs to be a time limit on the duration between the tag
and the roll... four days sounds good (if not excessive). That's what
killed 2.0.23 and 2.0.24 in a way... they took too damned long. At least
if we spread it out over a couple days, we don't twiddle our thumbs for a
week after we realize that the tarball we just rolled is broken for some
piddly-ass reason or another. Besides, if we wait a day or two between
the tag and the roll, there would never BE a reason to release every day,
so that problem just vanishes for free.
> And it would go a long way towards pissing off our testers. We have people
> who download the tarball when we release it, and if we replace that tarball
> after just a few hours,
Whoa... time out. I'm saying (and I think Bill is, too), that we *do not*
replace the tarball. Once it's rolled, that's it. If the tarball's
broken, try again with a new tag later. We can easily test it for obvious
flaws ourselves between the tag and the roll. Once *we're* satisfied,
roll it and give it to the testers. If they're satisfied, release.
That's what we did on 2.0.22 and 2.0.23, and they very nearly made it.
2.0.24 took the re-roll-a-thousand-times approach as an approximation of
the method, and it was also close (though I seriously dislike the
re-rolling part). But if we think that just snapshotting the tree and
then doing it again a week later is sufficient to ever get a server that's
release-quality, we're kidding ourselves IMO.
> We would easily get to a beta or production release, if we didn't keep
> changing the internals of the server, or if we posted large patches
> before they were committed, or if people ran the
> httpd-test/perl-framework test suite before committing, and if people
> would write tests once they fix a bug. The problem we have right now,
> is that most people don't use the test-suite, so even though it is
> catching most of the bugs when they are committed, nobody knows it.
At least on this front, I'm in total agreement... the httpd-test suite is
excellent. I've gotten to where I rely on it heavily to test any change I
make (even small ones) before committing, because it's so good at sniffing
out the subtle (and not-so-subtle) problems. If everybody used it, we'd
be set.
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: 2.0.26?
Posted by Ryan Bloom <rb...@covalent.net>.
On Thursday 30 August 2001 06:38, Bill Stoddard wrote:
> > On Wednesday 29 August 2001 21:18, Justin Erenkrantz wrote:
> > > On Wed, Aug 29, 2001 at 09:17:32PM -0700, Ian Holsman wrote:
> > > > On Wed, 2001-08-29 at 20:22, Justin Erenkrantz wrote:
> > > > > Should we be at 2.0.26-dev in ap_release.h? -- justin
> > > >
> > > > should we re-roll&tar 26 (which would include a patch to worker and
> > > > ldap_cache, some NW fixes and the apr-dbm change)
> > > >
> > > > or just re-tag the 2 files modified as 25 and re tar?
> > >
> > > We shouldn't re-roll 2.0.25. We need to T&R 2.0.26 instead, IMHO.
> > >
> > > We also need the just-committed mod_mime fix. I'll leave the
> > > rolling to someone who has done it before (rbb?). Try, try,
> > > again.
> > >
> > > I'm verifying wrowe's commit right now. It looks right. =)
> > > See if it works right... -- justin
> >
> > We shouldn't do either. If you go back and read the original thread,
> > one of the general rules of this release strategy is that we don't
> > release every day. We just rolled a tarball, and announced it to the
> > new-httpd, so there are people testing it at this point. That tarball
> > has to stand or fall on it's own. In a week, we can re-roll 2.0.26, and
> > try again.
> >
> > This, BTW, is why I originally stated that this release mechanism
> > wouldn't work. We keep on trying to improve the server, which means that
> > people keep changing core parts of the server. Either people need to
> > stop doing that, and just focus on fixing bugs, or we all need to accept
> > that we will be stuck with just one beta for a VERY long time.
> >
> > Ryan
>
> Completely agree that our release strategy (with Dr. Evil quotes around
> strategy) is broken. But we should be able to tag the tree anytime, IMHO.
> If HEAD is good, I am for tagging 2.0.26 and testing it but let's not roll
> the tarball. Fix any problems in 2.0.26 and bump the tag on affected files.
> When we are satisfied, roll 2.0.26. Put a time limit on the whole process
> of say, 4 days. If the time limit is exceeded (showstopper problems have
> not been driven out within 4 days of the tag) or the rolled tarball has
> showstoppers, consider the beta effort a failure and move on.
>
> This is basically what we did with 2.0.24 and it was almost successful.
> 2.0.24 dragged on a bit too long (over a week) and we rolled a couple of
> different 2.0.24 tarballs, which was not cool. Tagging a good HEAD,
> incrementally fixing showstoppers (provided the fixes are relatively
> limited in scope and simple) and bumping the tag on affected files, and
> exercising a little disipline and restraint for a few days (even just a few
> hours) prior to our target for rolling a beta would go a long way to
> solving this problem.
And it would go a long way towards pissing off our testers. We have people
who download the tarball when we release it, and if we replace that tarball
after just a few hours, then we are basically telling them that we don't need
their input, and they are only useful if they actually follow new-httpd, which
I think we all know is INCREDIBLY hard to do most days.
tag and roll and test. If that one isn't good enough, then we do it again a week
later. We would easily get to a beta or production release, if we didn't keep
changing the internals of the server, or if we posted large patches before
they were committed, or if people ran the httpd-test/perl-framework test suite
before committing, and if people would write tests once they fix a bug. The
problem we have right now, is that most people don't use the test-suite, so
even though it is catching most of the bugs when they are committed, nobody
knows it.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: 2.0.26?
Posted by Bill Stoddard <bi...@wstoddard.com>.
> On Wednesday 29 August 2001 21:18, Justin Erenkrantz wrote:
> > On Wed, Aug 29, 2001 at 09:17:32PM -0700, Ian Holsman wrote:
> > > On Wed, 2001-08-29 at 20:22, Justin Erenkrantz wrote:
> > > > Should we be at 2.0.26-dev in ap_release.h? -- justin
> > >
> > > should we re-roll&tar 26 (which would include a patch to worker and
> > > ldap_cache, some NW fixes and the apr-dbm change)
> > >
> > > or just re-tag the 2 files modified as 25 and re tar?
> >
> > We shouldn't re-roll 2.0.25. We need to T&R 2.0.26 instead, IMHO.
> >
> > We also need the just-committed mod_mime fix. I'll leave the
> > rolling to someone who has done it before (rbb?). Try, try,
> > again.
> >
> > I'm verifying wrowe's commit right now. It looks right. =)
> > See if it works right... -- justin
>
> We shouldn't do either. If you go back and read the original thread,
> one of the general rules of this release strategy is that we don't release
> every day. We just rolled a tarball, and announced it to the new-httpd,
> so there are people testing it at this point. That tarball has to stand or
> fall on it's own. In a week, we can re-roll 2.0.26, and try again.
>
> This, BTW, is why I originally stated that this release mechanism wouldn't
> work. We keep on trying to improve the server, which means that people
> keep changing core parts of the server. Either people need to stop
> doing that, and just focus on fixing bugs, or we all need to accept that we
> will be stuck with just one beta for a VERY long time.
>
> Ryan
>
Completely agree that our release strategy (with Dr. Evil quotes around strategy) is
broken. But we should be able to tag the tree anytime, IMHO. If HEAD is good, I am for
tagging 2.0.26 and testing it but let's not roll the tarball. Fix any problems in 2.0.26
and bump the tag on affected files. When we are satisfied, roll 2.0.26. Put a time limit
on the whole process of say, 4 days. If the time limit is exceeded (showstopper problems
have not been driven out within 4 days of the tag) or the rolled tarball has showstoppers,
consider the beta effort a failure and move on.
This is basically what we did with 2.0.24 and it was almost successful. 2.0.24 dragged on
a bit too long (over a week) and we rolled a couple of different 2.0.24 tarballs, which
was not cool. Tagging a good HEAD, incrementally fixing showstoppers (provided the fixes
are relatively limited in scope and simple) and bumping the tag on affected files, and
exercising a little disipline and restraint for a few days (even just a few hours) prior
to our target for rolling a beta would go a long way to solving this problem.
Bill
Re: 2.0.26?
Posted by Ryan Bloom <rb...@covalent.net>.
On Wednesday 29 August 2001 21:18, Justin Erenkrantz wrote:
> On Wed, Aug 29, 2001 at 09:17:32PM -0700, Ian Holsman wrote:
> > On Wed, 2001-08-29 at 20:22, Justin Erenkrantz wrote:
> > > Should we be at 2.0.26-dev in ap_release.h? -- justin
> >
> > should we re-roll&tar 26 (which would include a patch to worker and
> > ldap_cache, some NW fixes and the apr-dbm change)
> >
> > or just re-tag the 2 files modified as 25 and re tar?
>
> We shouldn't re-roll 2.0.25. We need to T&R 2.0.26 instead, IMHO.
>
> We also need the just-committed mod_mime fix. I'll leave the
> rolling to someone who has done it before (rbb?). Try, try,
> again.
>
> I'm verifying wrowe's commit right now. It looks right. =)
> See if it works right... -- justin
We shouldn't do either. If you go back and read the original thread,
one of the general rules of this release strategy is that we don't release
every day. We just rolled a tarball, and announced it to the new-httpd,
so there are people testing it at this point. That tarball has to stand or
fall on it's own. In a week, we can re-roll 2.0.26, and try again.
This, BTW, is why I originally stated that this release mechanism wouldn't
work. We keep on trying to improve the server, which means that people
keep changing core parts of the server. Either people need to stop
doing that, and just focus on fixing bugs, or we all need to accept that we
will be stuck with just one beta for a VERY long time.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: 2.0.26?
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Wed, Aug 29, 2001 at 09:17:32PM -0700, Ian Holsman wrote:
> On Wed, 2001-08-29 at 20:22, Justin Erenkrantz wrote:
> > Should we be at 2.0.26-dev in ap_release.h? -- justin
>
>
> should we re-roll&tar 26 (which would include a patch to worker and
> ldap_cache, some NW fixes and the apr-dbm change)
>
> or just re-tag the 2 files modified as 25 and re tar?
We shouldn't re-roll 2.0.25. We need to T&R 2.0.26 instead, IMHO.
We also need the just-committed mod_mime fix. I'll leave the
rolling to someone who has done it before (rbb?). Try, try,
again.
I'm verifying wrowe's commit right now. It looks right. =)
See if it works right... -- justin
Re: 2.0.26?
Posted by Cliff Woolley <cl...@yahoo.com>.
On 29 Aug 2001, Ian Holsman wrote:
> should we re-roll&tar 26 (which would include a patch to worker and
> ldap_cache, some NW fixes and the apr-dbm change)
>
> or just re-tag the 2 files modified as 25 and re tar?
It'd be nice if it built on BeOS. ::prod, prod:: :-) I vote for 26
tomorrow midday to fix these issues. I'll volunteer to RM since Ryan's
already done it once in 24 hours. =-)
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: 2.0.26?
Posted by Ian Holsman <Ia...@cnet.com>.
On Wed, 2001-08-29 at 20:22, Justin Erenkrantz wrote:
> Should we be at 2.0.26-dev in ap_release.h? -- justin
should we re-roll&tar 26 (which would include a patch to worker and
ldap_cache, some NW fixes and the apr-dbm change)
or just re-tag the 2 files modified as 25 and re tar?
--
Ian Holsman
Performance Measurement & Analysis
CNET Networks - 415 364-8608