httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Richards <>
Subject Re: background CGI bug
Date Fri, 03 May 1996 08:57:03 GMT
In reply to Alexei Kosut who said
> 2. March 1, 1996 was the date that I committed the first bunch of
>    patches to CVS after Paul & Ben set it up. The CGI problem must
>    have been in there somewhere. That's a lot of code; a rough
>    educated guess is that over 2000 lines of code changed during
>    that time period (out of 22,000 in Apache total). That's almost
>    10%. I say good luck finding the part that broke the CGI script...

If you have the separate patch files then checkout out Apache after that
mammoth commit and use patch to individually remove each of the patch files
you committed from the checked out copy. That'll allow to regressively
test each patch until you find the culprit.

Lesson learnt. Don't commit lots of work in one go (not your fault in this
case but it serves as an example). Commit changes that do one particular
task so in future it's easy to nail down a particular change.

> 3. In regard to people not testing... well, those patches were all
>    sitting in httpd/incoming/patches for a while... I built two
>    pre-CVS releases containing the patches. I made sure that everyone
>    agreed that they should be included. So it may in fact have nothing
>    to do with CVS. Same thing would have happened with patch-and-vote
>    because, in fact, these patches *were* voted upon.

The distribution of the development tree is still not very good. I'm
completely swamped at the moment and can't look into this but perhaps
we should create daily/hourly deltas against the previous day so people
can grab a smallish patch file each night to get that days commits.

Other things I want to do but don't have time is pull the 1.0.x releases
into the 1.0 branch so we don't lose them.

What we really need is ctm. Any FreeBSD folk out there (seems to be a 
growing number) who want to port ctm to other platforms and set up the
server on hyperreal.

I've been thinking about branching policies. Given that we don't have a very
good record at release testing I don't think allowing development to 
continue duing releases is a good idea since people don't spend enough time
testing and fixing bugs in a release as it is and allowing development to 
carry on on a separate branch would make things worse.

I suggest we continue with feature freeze periods leading up to releases and
then branch after release so development can continue while giving us the
option to do post-release bug fixes on the last release, like we did with
1.0.x but using cvs.

  Paul Richards. Originative Solutions Ltd.  (Netcraft Ltd. contractor)
  Elsevier Science TIS online journal project.
  Phone: 0370 462071 (Mobile), +44 (0)1865 843155

View raw message