httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@kiwi.ics.uci.edu>
Subject Re: cvs commit: apache-1.3 WARNING-NT.TXT
Date Mon, 21 Sep 1998 02:15:29 GMT
>> Marc, why is it I have to continually remind you to read the guidelines?
>
>Erm... if you could point out this "continually" I would appreciate it.

Every time anyone vetos something and you disagree, you bitch about
not only what they are vetoing, but the fact that they can veto at all.
And then you say something incredibly stupid like you are going
to veto the release until you are satisfied, which is not something
that any of us can veto.

The veto exists because we found it impossible to keep the server
distribution from bloating all to hell with just a majority vote.
It is our method of quality control and it works damn well considering
the environment.

>> A veto can be used to remove stuff from the release.  A veto cannot be
>> used to stop a release.  If two or more of us disagree and cannot resolve
>> the issue, then it doesn't get included in the release.  End of story.
>
>Sorry, no.  Based on the commit-then-review rules, if someone disagrees
>with a commit it is backed out after the fact.  The veto is not for
>stopping the release, the veto would be for the inappropriate change you
>made.
>
>From the c-t-r rules:
>
>    A committed change must be reversed if it is vetoed by one of the
>    voting members and the veto conditions cannot be immediately satisfied
>    by the equivalent of a "bug fix" commit. The veto must be rescinded
>    before the change can be included in any public release.
>
>It is only common sense that in c-t-r a veto requires backing out the
>change until resolved and not releasing anything with the change in
>until it is resolved.

Common sense?  I removed something that was added specifically for 1.3.1
because of known security holes in that particular release.  If you want
to add it again for 1.3.2, then justify what it says.  That is common sense.
I don't care whether you term this a veto on the original commit or an
insistence that we don't publish bullshit that no longer applies to
the current release.

>They have been discussed over and over.
>
>If I had the time or interest to fix them they would be fixed.

They aren't getting fixed because nobody has asked that they be fixed.
AFAICT, the problems either don't exist or have already been fixed in
1.3.2-dev.

>There are still likely issues with pathname resolution on Win32, there are
>numerous areas where you can make it segv and pop up a dialog box and
>block the whole server until you hit ok, the default install runs
>everything as a priv.'d user, we require people to store passwords 
>in plain text, there are bogus assert()s all over the win32 code that make
>apache crap out with useless warnings, etc.  I can't think of them all at
>the moment.

Well, can someone who does have an hour free put together a list that
is based on more than just vague memory?  I also recall all these things
being discussed at the beginning of summer, but not with enough specifics
to allow one of our volunteers to track them down and fix them.

>things in particular that are wrong with it.  It looks to me that you are
>coming in from the "outside", never having seriously looked at the code
>and never having been involved with it and saying "hey, looks fine to me,
>there can't be any problems."

Of course there are problems with it. There are problems with Apache on all
of our platforms.  Bitching about it on one platform doesn't make us
look any better, nor has it helped solve any of those problems.  In fact,
by all appearances it has just turned people away from helping.

>> If you don't want Apache to be distributed on Windows then by all means
>> remove the Win32 support from the source.
>
>Do we have to go through this over and over?  We are trying to DEVELOP a
>server that works on Win32.  We either need completely different
>versioning, or we have to hold up the Unix version forever, or we have to
>release something that is not release quality on Windows.  There are no
>magic fairies that will just make the code be fixed without anyone doing
>it.

Been there, done that.  It isn't rocket science and it doesn't justify
a pop-up warning during the installation process.  The contents of the
readme are sufficient and placed in the proper context so that a user
can find out exactly what is wrong if they so desire.

....Roy

Mime
View raw message