httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <>
Subject Re: 2.0.26?
Date Thu, 30 Aug 2001 20:53:37 GMT

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

> 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 Bloom
Covalent Technologies

View raw message