httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Richards <p.richa...@elsevier.co.uk>
Subject Re: cvs commit: apache/src mod_rewrite.h Makefile.tmpl (fwd)
Date Mon, 18 Nov 1996 10:46:55 GMT
Brian Behlendorf <brian@organic.com> writes:

> closer to release we get.  Things like the "satisfy"  functionality definitely
> cross it, at this stage. 

Ehh? Rob's last todo list had getting a satisfy patch ASAP as one of
the tasks, the feature freeze was Sunday 17 November, I added that
feature before feature freeze.  Are we now saying that although a
particular date is a feature freeze date that we shouldn't add new
features too close to it!

The patch compiled clean on my box (I've just checked and -Wall isn't
enabled when you build Apache out of the box). I've been running with
it since last night and it hasn't broken anything. I've just compiled
it with -Wall and there are two implicit declarations, certainly I'd
want them cleaned up but they're hardly major disasters. I'd go and fix
it but seems that the satisfy patch is pulled. I didn't test the patch
as much as it should have been but there was a deadline and it was a
feature freeze deadline not a code freeze, feature freeze deadlines
are for adding features, there has to be a period afterwards where
they are checked and tested.

I've always been against voting. This is the only project I've ever
been involved in that has these procedures and Apache is a lot simpler
than most of them. Using cvs the way we have been has accelerated
progress considerably. I don't see that we've got a less stable product
as a result. Has anyone got any evidence to the contrary? Allowing one
person a veto is just stupid. When most of the group are thinking one
way why should a single individual be allowed to prevent something
happening.

The problem is that some people haven't bothered learning cvs and
insist that the old methods are run in parallel so they can see what's
going on. Peer review should take place continuously on the whole
system, there's a major ego thing here in that some people want to
examine every little change that's made, things won't work long term
if that's the attitude. If the server is working then fine, if it
breaks then cvs is a good tool for finding out why and fixing it. The
vast majority of changes that people commit are fine, why burden
people with unecessary bureacracy. If you want to peer review changes
then peer review them, it's a doddle to do so. In fact, it's a hell of
a lot better peer review changes by running the server than it is by
trying to read a patch.


-- 
  Paul Richards. Originative Solutions Ltd.  (Netcraft Ltd. contractor)
  Elsevier Science TIS online journal project.
  Email: p.richards@elsevier.co.uk
  Phone: 0370 462071 (Mobile), +44 (0)1865 843155

Mime
View raw message