httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From d...@ast.cam.ac.uk (David Robinson)
Subject Re: patch - vote
Date Mon, 12 Feb 1996 12:18:00 GMT
>We are voting on what to release as "the Apache HTTP Server".

That's news to me. I thought we were voting on the first version which will
become 1.1

>We *cannot* release a peice of software that we know, weeks in advance, will
>not work at all on common hardware platforms, like Linux, or SunOS, or HP-UX. 
>There are no doubt hundredes of thousands of people running these operating
>systems. We cannot release software that is so blatantly broken that it won't
>even compile.

Who said we were?

>That is why we *have* the patch, test, and vote system. Someone writes a 
>patch. They submit it. If it gets voted down, they can submit it again 
>next time. That's why we will have a number of these runs before we 
>release 1.1. If it doesn't make it this time, just wait a couple weeks, 
>fix the problems, and we'll try again.

Not only is that counter productive, it is also not the way we have worked
in the past. (Before you joined, I think).

Yes, when we are preparing for a final, non-beta release we should be
very careful with each patch.

But when we are devoping a new release, are standards are neccesarily lower.
To enable the project to progress, we must accept partial solutions, with
fixes to come later. Otherwise, we grind to a halt.

I was certainly shot down in flames last summer for vetoing patches which
I didn't consider 'perfect' by my standards.

>But at no time can we give the public, or even members of this group, a 
>HTTP server that will not work. At all. Which is what some of these 
>patches make some systems do. And that's what vetoes are for.

That's always been the case.

To take particular examples: yes, I agree that a patch prevents compilation
on Linux should be fixed before a new internal version is compiled.

However, what about your keep-alive patch?
I don't like some of it. So should I veto it (because it's a memory hog, say),
forcing _you_ to fix and resubmit, or should I not veto it, allowing it into
the Apache code, where you or _anybody else_ can fix the bugs?

 David.

Mime
View raw message