You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Brian Behlendorf <br...@hyperreal.org> on 1998/01/09 00:18:14 UTC
holy pete PLEASE READ
What is it with the electrosphere today? In the course of only a few hours,
1) I blow away my home directory on hyperreal thanks to something broken in
Freebsd's "pkg_add" util. There's two hours gone from a rather overbusy day.
2) A new exploit against TCP stacks based on teardrop is discovered.
Bingo, machines are down all over.
3) A discussion about ways to make development easier for folks explodes
into attacks and threats of resignation.
I haven't even caught up to all the messages today, but I caught Dean's.
Dean, not everyone (including particularly me) had weighed in on the topic
of adding those steps to the dev process. The thread just started this
morning! During the summer we *did* have lazy voting rules in place, and
you *did* go in and commit patches without getting 3 +1 votes from others,
as did a few others, and that seemed to work fine, and a lot got done.
BUT we're "supposed" to be in a different stage now, and that is wrapping
up of 1.3. You and others are absolutely right to say "what the fuck?
we've been adding new features anyways." The problem is that those of us
who have wanted to wrap up 1.3 and move on to 1.4 or 2.0 have stood back
while you've pushed forth a tremendous (and always high quality) number of
enhancements. This has been a good thing, but it doesn't mean we don't
want to wrap up 1.3 and move on - it means we don't want to stand in the
way of a lot of good work going on.
So there's a tension there we need to RESOLVE RIGHT HERE AND RIGHT NOW.
And that tension is between "release engineering" and "enhancements". Let
me make an honest proposal along the lines of fixing this.
I say we approve/veto the last set of patches in the STATUS file and
release 1.3b4, and then within a week "1.3.0". Yes, the NT port isn't
perfect, it's not as stable or nice as Apache on Unix; we have to bite the
bullet and accept that. We've already accepted that the current thread
model doesn't work perfectly on NT anyways.
Along with this, we need to get **out of our mind the concept that a
"final" release has the same level of release engineering as a commercial
product**. I think too many of us are operating from a standard software
engineering background, where you do the basic work and then spend 3 months
without adding new features squishing bugs, and then releasing the code.
That model, unfortunately, requires more discipline than we could ever
have. And in the world of free software development, I don't think it's
necessary. If Macromedia releases CoolEdit 8.0 and it contains a serious
flaw, it's very very expensive for them (cost + overhead) to distribute
fixes. For us, it's really really easy to distribute new releases; in fact
the world might just be a better place if we release a minor version of 1.3
every few weeks, every time there's a modest improvement in internals or
features. We should stop seeing minor version number increases as
embarrassments and more as enhancements.
So, again, my proposal is to release 1.3b4 quite quickly, and "1.3.0" soon
after that. Notice I'm hesitant to use the word "final", for obvious
reasons.
Before tackling the issue of peer review, let me tackle a smaller one, that
of tracking patches for review. What we need is a fast way to look up
patches that are referenced in STATUS files. A proposal was made to use
CVS. I propose we store them on the dev.apache.org web site instead. The
storage process could be automated: every time a message comes through
whose subject line matches "Subject: [PATCH]", it gets stored in a
subdirectory under dev.apache.org, perhaps with the message-ID as its
filename. When a patch is committed, or obsolesced, it gets removed.
How does this sound? What issues doesn't it address?
We could get fancier and build what I've wanted to build for a couple years
now which is a proper WWW gateway to mailbox files (which does rendering to
HTML/threading on the fly, searchable by msgid/from/to/subject/thread etc),
but a simple directory is more pragmatic.
On the topic of the existance of apache-core. What can I say? Dean said
it all. The list of members mirrors the Apache Group members as described
at <http://www.apache.org/contributors/>. It was started as an attempt to
start the process of incorporating the Apache Project as a non-profit; but
just as the 2.0 development process has been stalled, it too has been
stalled by issues such as dealing with security, licensing questions, legal
questions, etc. I think everyone is sincere in the belief that
incorporating as a non-profit is a good thing to do and possible, though we
all get frustrated at the slow pace.
My hands have been tied for too long by only being able to commit a few
hours a day to this. I intend to change this soon.
> At the same time I would appreciate it if you would add dgaudet@apache.org
> to security@apache.org, as I do wish to continue to develop.
You've been added to that alias. And I do hope you continue developing; as
I hope I explained above, there is a tension caused by the fact that you do
a lot of high quality work, and our model is being severely tested by that.
I know you don't want to be the "Linus" (or Caesar) of the Apache project,
but you have to understand concerns about such a thing happening. *I*
think we can develop safeguards against it, and I'm willing to experiment
with loosening the process a bit. And if anyone's concerned about
Caesarship I'm the one folks should be worried about, as I'm the only one
with root on apache.org! :)
So, folks, can we try and find a way to make this work? Please?
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
"Optimism is a strategy for making brian@apache.org
a better future." - Noam Chomsky brian@hyperreal.org
Re: is 1.3 ready? lingering NT issues.
Posted by Brian Behlendorf <br...@organic.com>.
At 05:53 PM 1/8/98 -0700, Marc Slemko wrote:
>There is a difference between being "strong" and being shoddy and possibly
>full of all sorts of security holes. I closer to the opinion of "it
>sucks, oh well... that's life, release as is" until I looked at the NT
>code.
I'll definitely buy the argument that the NT port deserves security
scrutiny before releasing 1.3.0. Beyond that, I'm not sure many bugs will
be found until it's put into a production system anyways. Maybe we should
run www.apache.org off my laptop. :)
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
specialization is for insects brian@organic.com
Re: is 1.3 ready? lingering NT issues.
Posted by Marc Slemko <ma...@worldgate.com>.
Oh, I really should add that I am _not_ faulting anyone, especially
Ambarish, but the simple fact is that not enough effort has yet gone into
it.
Re: is 1.3 ready? lingering NT issues.
Posted by Marc Slemko <ma...@worldgate.com>.
On Thu, 8 Jan 1998, Brian Behlendorf wrote:
> At 05:09 PM 1/8/98 -0700, Marc Slemko wrote:
> >I really am not convinced that releasing the win32 tree in anything
> >resembling what it is now does anyone any good.
> >
> >It destroys any reputation of good solid code Apache may have.
> >
> >There are real problems that need to be addressed.
> >
> >While it may not look like it from the outside, the more I look
> >at the NT port the more I see serious issues that need to be
> >fixed. Heck, CGI scripts called in the form http://foo/cgi-bin/bar.exe/foo
> >(ie. PATH_INFO w/o an =) don't even work in the current tree, and I
> >am willing to bet there are a _lot_ more issues including problems
> >with non-thread safe modules, eg. changing cwd.
> >
> >We have a real problem with NT because we don't have many developers
> >who do anything with it, we don't have many people that understand
> >the very different way NT does things (I sure don't), and there are
> >no where near as many NT people in the world that can or will
> >contribute code.
>
> Then by the laws of the jungle, that means the NT port will not be as
> strong as the Unix code, and in a volunteer project like this we'll have to
There is a difference between being "strong" and being shoddy and possibly
full of all sorts of security holes. I closer to the opinion of "it
sucks, oh well... that's life, release as is" until I looked at the NT
code.
> accept that. We can't compell anyone to develop anything which doesn't
> provide some benefit to working on that. And the simple fact of the matter
> is that the culture of NT users is a world away from that of Unix users.
> NT users are used to complaining about a problem but not having the tools
> or ability to go in and fix it themselves, and since NT software is
> typically expensive, someone's getting paid to support it and new fixes
> will eventually happen. Unix users are using to having the tools and never
> needing to complain, since they don't spend enough to be able to pay anyone
> to pay attention to them anyways.
>
> While advocating for an NT port, I too realized this would be the biggest
> problem. I have a copy of NT and MSVC at home now and I'm getting up to
> speed on it, but it'll be a long while before I've got anywhere near enough
> proficiency to be able to bring it up to the quality that the unix side sees.
>
> Maybe we need to proselytize in the "NT Developer" community more? Maybe
> we should prod others doing NT freeware work for ideas? (who would they
> be?) Heck, if Microsoft were to have someone join new-httpd and
> participate, the NT side could probably be cleaned up quickly. I'm sure
> the last thing Microsoft wants is the most popular web server in the world
> making NT look bad in comparison to Unix, especially if it's through no
> direct fault of NT itself.
>
> All I know is one thing we can't do is stifle progress because of lack of
> NT solidity. Because to be honest, the NT port is going to be ignored by a
> large number of folks until it has a GUI and a one-button install and
> direct support for FrontPage and yadda yadda yadda; if in a 1.3.0
> announcement we say "NT works, but has a couple bugs" I don't think we're
> going to lose many converts.
If it went out at the current point, I would suggest we should have to say
"the NT port is not yet functional and should not be used for production
sites or anything other than basic test purposes because there are many
bugs in it still."
I'm not overly interested in NT since I never use it for anything other
than amusement, but I'm trying to look at some of the more obvious
problems.
is 1.3 ready? lingering NT issues.
Posted by Brian Behlendorf <br...@organic.com>.
At 05:09 PM 1/8/98 -0700, Marc Slemko wrote:
>I really am not convinced that releasing the win32 tree in anything
>resembling what it is now does anyone any good.
>
>It destroys any reputation of good solid code Apache may have.
>
>There are real problems that need to be addressed.
>
>While it may not look like it from the outside, the more I look
>at the NT port the more I see serious issues that need to be
>fixed. Heck, CGI scripts called in the form http://foo/cgi-bin/bar.exe/foo
>(ie. PATH_INFO w/o an =) don't even work in the current tree, and I
>am willing to bet there are a _lot_ more issues including problems
>with non-thread safe modules, eg. changing cwd.
>
>We have a real problem with NT because we don't have many developers
>who do anything with it, we don't have many people that understand
>the very different way NT does things (I sure don't), and there are
>no where near as many NT people in the world that can or will
>contribute code.
Then by the laws of the jungle, that means the NT port will not be as
strong as the Unix code, and in a volunteer project like this we'll have to
accept that. We can't compell anyone to develop anything which doesn't
provide some benefit to working on that. And the simple fact of the matter
is that the culture of NT users is a world away from that of Unix users.
NT users are used to complaining about a problem but not having the tools
or ability to go in and fix it themselves, and since NT software is
typically expensive, someone's getting paid to support it and new fixes
will eventually happen. Unix users are using to having the tools and never
needing to complain, since they don't spend enough to be able to pay anyone
to pay attention to them anyways.
While advocating for an NT port, I too realized this would be the biggest
problem. I have a copy of NT and MSVC at home now and I'm getting up to
speed on it, but it'll be a long while before I've got anywhere near enough
proficiency to be able to bring it up to the quality that the unix side sees.
Maybe we need to proselytize in the "NT Developer" community more? Maybe
we should prod others doing NT freeware work for ideas? (who would they
be?) Heck, if Microsoft were to have someone join new-httpd and
participate, the NT side could probably be cleaned up quickly. I'm sure
the last thing Microsoft wants is the most popular web server in the world
making NT look bad in comparison to Unix, especially if it's through no
direct fault of NT itself.
All I know is one thing we can't do is stifle progress because of lack of
NT solidity. Because to be honest, the NT port is going to be ignored by a
large number of folks until it has a GUI and a one-button install and
direct support for FrontPage and yadda yadda yadda; if in a 1.3.0
announcement we say "NT works, but has a couple bugs" I don't think we're
going to lose many converts.
Maybe we should pull a Sendmail and come out with Apache 4.0?
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
specialization is for insects brian@organic.com
RE: holy pete PLEASE READ
Posted by Lars Eilebrecht <La...@unix-ag.org>.
According to Brian Behlendorf:
> I say we approve/veto the last set of patches in the STATUS file and
> release 1.3b4, and then within a week "1.3.0". Yes, the NT port isn't
> perfect, it's not as stable or nice as Apache on Unix; we have to bite the
> bullet and accept that. We've already accepted that the current thread
> model doesn't work perfectly on NT anyways.
IMHO this is not a good idea...
Looking at the bugdb there are several Windows specific PRs that
should be addressed before releasing 1.3.0.
Apart from the fact that I don't do any Windows-stuff I think that
the Windows-port is very important for the 1.3.0 release.
Many people are testing the Windows version and are probably waiting
for the final version to use it on a production server. I think we
will loose many of the Windows-people if we release a 'buggy' 1.3.0.
Reading the index page at www.apache.org I'm seeing the following
sentence:
The goal of this project is to provide a secure, efficient and extensible
server which provides HTTP services in sync with the current HTTP standards.
Do you think the current Windows-port has reached this goal?
If not the 1.3.0 release should wait until this goal is achieved and the
Apache Group *really* can recommend Windows people to use Apache!
Only Microsoft has a 'release-and-fix-later'-mentality... the Apache Group
has shown in the past that a final version really is *final*.
> For us, it's really really easy to distribute new releases; in fact
> the world might just be a better place if we release a minor version of
> 1.3 every few weeks, every time there's a modest improvement in internals
> or features.
But if the first 'final' Windows version is unstable the Apache Group will
loose some its good reputation, IMHO.
[...]
> So, again, my proposal is to release 1.3b4 quite quickly, and "1.3.0" soon
> after that. Notice I'm hesitant to use the word "final", for obvious
> reasons.
As you already mentioned, Apache is no commercial product and therefore
there are no fixed release dates. 1.3 beta cycle maybe takes longer than
expected, but porting Apache to a completely different platform like
Windows takes its time. The developers who are working on the Windows port
are doing a great job, but releasing an 'unstable' Windows-port as 1.3.0
won't help the Windows-folks nor the Apache Group.
As always... just my $0.02. :)
P.S.: Switching to lazy voting for all Windows-specific stuff may speeds
things up...
ciao...
--
Lars Eilebrecht - Reality is an illusion...
sfx@unix-ag.org - caused by a lack of alcohol
http://www.si.unix-ag.org/~sfx/
Re: holy pete PLEASE READ
Posted by Marc Slemko <ma...@worldgate.com>.
On Fri, 9 Jan 1998, Rodent of Unusual Size wrote:
> Marc Slemko wrote:
> >
> > I really am not convinced that releasing the win32 tree in anything
> > resembling what it is now does anyone any good.
> >
> :
> > There are real problems that need to be addressed.
>
> I agree. One of them is the InstallShield packaging, which Ben
> said is humongously obnoxious for things like the htdocs tree.
> Is Ben still doing the IS work, or did that get handed off to
> someone else? I forget..
>
> I'd like to see the major Win32 issues fixed, 1.3.0 released, and
> maybe a 1.[34]* to clean up any warts. And a 1.4 for those of
> us with bulging feature pouches.
Call the next version 2.0. Go for the full API/process model/etc.
changes. What gets done gets done, we are well overdue for a 2.0 anyway.
The actual time to get it done and coded will be very small. 90% of the
time is spent with bugfixes, dealing with release cycles, creative
discussion, etc. We can not do a short 1.4 release cycle. We can not
support making 2.0 and 1.4 go on at the same time. History is a good
teacher.
Re: holy pete PLEASE READ
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Marc Slemko wrote:
>
> I really am not convinced that releasing the win32 tree in anything
> resembling what it is now does anyone any good.
>
:
> There are real problems that need to be addressed.
I agree. One of them is the InstallShield packaging, which Ben
said is humongously obnoxious for things like the htdocs tree.
Is Ben still doing the IS work, or did that get handed off to
someone else? I forget..
I'd like to see the major Win32 issues fixed, 1.3.0 released, and
maybe a 1.[34]* to clean up any warts. And a 1.4 for those of
us with bulging feature pouches.
#ken P-)}
Re: holy pete PLEASE READ
Posted by Marc Slemko <ma...@worldgate.com>.
On Thu, 8 Jan 1998, Brian Behlendorf wrote:
> I say we approve/veto the last set of patches in the STATUS file and
> release 1.3b4, and then within a week "1.3.0". Yes, the NT port isn't
> perfect, it's not as stable or nice as Apache on Unix; we have to bite the
> bullet and accept that. We've already accepted that the current thread
> model doesn't work perfectly on NT anyways.
I really am not convinced that releasing the win32 tree in anything
resembling what it is now does anyone any good.
It destroys any reputation of good solid code Apache may have.
There are real problems that need to be addressed.
While it may not look like it from the outside, the more I look
at the NT port the more I see serious issues that need to be
fixed. Heck, CGI scripts called in the form http://foo/cgi-bin/bar.exe/foo
(ie. PATH_INFO w/o an =) don't even work in the current tree, and I
am willing to bet there are a _lot_ more issues including problems
with non-thread safe modules, eg. changing cwd.
We have a real problem with NT because we don't have many developers
who do anything with it, we don't have many people that understand
the very different way NT does things (I sure don't), and there are
no where near as many NT people in the world that can or will
contribute code.
I was quite worried about this sort of thing happening before we
decided to do a "quick" 1.3 and I ma still worried about it.
IMO, this is the basis of the problem with why 1.3 is taking so long to
get out.
I can't comment on 1.2 since I wasn't even around at the start of that
beta cycle. That, in itself, says a lot.