I think Apache's core has become stable and very solid
(just like TCP/IP stack). It has a very good modules
architecture. Most of the new features are added as module.
There are no need to add more features to the httpd core.
Apache is not MS and does not need to add more features
to the core
Ok, so Apache2 uptake is slower than desired for some (not all) on this
list. That's only logical given the success and therefore inertia to stay
with Apache 1.3. But there are more than a few other factors mentioned in
recent threads that are contributing to Apache2 development stagnation.
Good Point I have noticed that there is still a large number of people that
use 1.3 and are upset cause they don't like whats going on with 2. I like
you idea we need to make it easyer for people to add to apache I find it
hard to even get people to do or help with little things. We have to many
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
Glenn wrote:
- lack of clear leadership and even basic direction
At present I see most of the time volunteered by developers to be spent
communicating with users on the bug db and trying to fix bugs. That sounds all
well and good to me.
If somebody wants something big implemented that they
I would not use this as an argument to re-open 1.3, but:
The LDAP authentication module has a number of issues which have been
languishing. I really cannot gripe as I haven't fixed any -- just found
some, but for some of us this module has become critical. Apache 2 has
incorporated LDAP
Thanks for your response, Jeff.
You present some excellent points and defenses and present worthy opinions.
I agree that there are lots of thankless, non-sexy tasks that would
help, but the core developers need more manpower. I am hoping to
create new avenues for participation.
My goal is to get
On Sun, 16 Nov 2003, Jeff Trawick wrote:
*** We need to get back many of the disenfranchised Apache 1.3 developers
Who are these people?
/me raises a hand
People have suggested that we have fewer developers today because Apache 2
is too complex. That the crappy economy has reduced the
Rasmus Lerdorf wrote:
*** We need to get back many of the disenfranchised Apache 1.3 developers
Who are these people?
/me raises a hand
Just compare the list of contributors today to 4 years ago if you want a
list.
diff knows no reasons.
Too bad all these supposedly-disenfranchised people
Rasmus Lerdorf wrote:
I also work for a large company with plenty of talented developers and
thousands of production Apache-1.3 servers along with hundreds of custom
Apache-1.3 modules. It will be years before I can even consider Apache2,
given the architecture and API differences between the
On Sun, 16 Nov 2003, Jeff Trawick wrote:
Too bad all these supposedly-disenfranchised people aren't around to review 1.3
fixes. 1.3 would be healthier if they were.
And it is the reason for why they are not around that is in question here.
Why wouldn't there be plenty of hackers around for
On Sun, 16 Nov 2003, Graham Leggett wrote:
I think the key thing is bugfixes compared to features and
architecture changes.
I am +1 on seeing bugfixes go into v1.3 - people are using it, and if it
can work better, so be it. But to actively encourage people to add
features or architecture
Rasmus Lerdorf wrote:
On Sun, 16 Nov 2003, Jeff Trawick wrote:
Too bad all these supposedly-disenfranchised people aren't around to review 1.3
fixes. 1.3 would be healthier if they were.
And it is the reason for why they are not around that is in question here.
Why wouldn't there be plenty
Hi,
I understand many people still are with 1.3 and don't want to change because
it's stable.
But Coding modules with 1.3 is definitively not easy and require many time
core patch.
Apache 2.0 was design to give many really good features like threaded mpm,
filters etc...
When you look others web
On Sun, 16 Nov 2003, Jeff Trawick wrote:
The point was not to blame anybody. Instead, I don't believe there are so many
people as you imply. Many of the people who are no longer developing have
moved on to other interests/work/etc. and have dropped out of httpd dev because
of that.
If
On Sun, Nov 16, 2003 at 12:04:28PM -0800, Rasmus Lerdorf wrote:
Basically I see us back in the NCSA days right now. The ASF has mostly
abandoned Apache1 and we are in that transition phase where people are
looking at each other waiting for someone to step up and continue
development on the
On Nov 16, 2003, at 4:12 AM, Glenn wrote:
- lack of clear leadership and even basic direction
scratch-an-itch development is fine and good, but not in total chaos
Umm... this *is* the ASF. It's *developer* driven. The direction
is defined by the developers.
- cathedral development
it appears
On Nov 16, 2003, at 2:23 PM, Glenn wrote:
I don't expect any of the current Apache developers would be
interested in
this. But plenty of people join the development community over time
(see
previous comments) and theoretically the opinions could change.
Well, I am interested. And some others
On Sun, 16 Nov 2003, Jim Jagielski wrote:
I'm curious how a 1.4 or whatever would make it easier for people to
make that transition. What would 1.4 have or be for that to happen?
I was kind of wondering this one too ... I thought the biggest headache of
moving from 1 - 2 was that the APIs
On Sun, Nov 16, 2003 at 03:37:19PM -0500, Jim Jagielski wrote:
As noted many times, 1.3 is actively maintained but not
actively developed. To be honest, I've not seen that
many people saying I *really* want to add this to 1.3!.
If they had, chances are good that I'd +1 (not that what
goes
On Sun, Nov 16, 2003 at 03:46:26PM -0500, Jim Jagielski wrote:
Why 1.4? What will 1.4 have that 1.3 does not? Or do you mean
reopening 1.3 implies that it becomes 1.4?
Only semantics. .4 is even, so stable; .5 is development and less stable
+1 for officially allowing active development on
On Nov 16, 2003, at 3:57 PM, Glenn wrote:
Oh, how about my (effectively) 2-line patch which adds vhost
to the error log, which I have posted to this list NO LESS THAN 6 TIMES
and spaced out over the past 6 MONTHS in three different formats, using
a global, expanding server_rec, and with #defines.
just to pop my 2 cents worth in here ... I have some clients that
have deployed under Apache2 ... the major headache(s) that I've had
to date is that the FreeBSD thread support is still listed as unusable:
* If you are building on FreeBSD, be aware that threads will
Glenn wrote:
On Sun, Nov 16, 2003 at 03:46:26PM -0500, Jim Jagielski wrote:
Why 1.4? What will 1.4 have that 1.3 does not? Or do you mean
reopening 1.3 implies that it becomes 1.4?
Only semantics. .4 is even, so stable; .5 is development and less stable
Personally, I've never liked
On Sun, Nov 16, 2003 at 04:12:20PM -0500, Jim Jagielski wrote:
On Nov 16, 2003, at 3:57 PM, Glenn wrote:
Oh, how about my (effectively) 2-line patch which adds vhost
to the error log, which I have posted to this list NO LESS THAN 6 TIMES
and spaced out over the past 6 MONTHS in three
On Sun, 16 Nov 2003, Paul Querna wrote:
just to pop my 2 cents worth in here ... I have some clients that
have deployed under Apache2 ... the major headache(s) that I've had
to date is that the FreeBSD thread support is still listed as unusable:
* If you are building on
On Sun, 16 Nov 2003 16:21:04 -0500
Glenn [EMAIL PROTECTED] wrote:
On Sun, Nov 16, 2003 at 04:12:20PM -0500, Jim Jagielski wrote:
I may be misunderstanding you... or do you mean just have
Apache 1.3 APR aware and not for 1.3 to *use* it per se,
but allow for modules to call APR... That would be
On Sun, 16 Nov 2003, Jim Jagielski wrote:
So a useful topic is: What is *missing* in 1.3 that needs to be
addressed.
What are the features/additions that the disenfranchised 1.3 developers
want to add to 1.3...
How about support for chunked compressed responses right in
src/main/buff.c
What exactly do people want in a 1.4 and why is making that fit into 2.0
not an option?
So far I can recall seeing a few reasons why people aren't moving to 2.0.
1. they have no need to change, so they don't. Why would having a
1.4 then 2.0 will make them have a need to make two changes? If
On Sun, 2003-11-16 at 11:11, Jeff Trawick wrote:
- patch management
many patches posted to this list or the bug db languish in limbo.
Very little happens until a core contributor decides to take over a patch
(more often than not it is more than simply shepherding it)
Little
I agree with Matt that Apache2 needs to be rdy for IIS but we need to make a
choice here between 1.3-1.4 and 2
-Kyle Hamilton
www.kylehamilton.net
www.kylehamilton.com
559-593-1210
- Original Message -
From: Matthieu Estrade [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday,
Ok, so Apache2 uptake is slower than desired for some (not all) on this
list. That's only logical given the success and therefore inertia to stay
with Apache 1.3. But there are more than a few other factors mentioned in
recent threads that are contributing to Apache2 development stagnation.
--On Sunday, November 16, 2003 4:04 PM -0500 Glenn
[EMAIL PROTECTED] wrote:
On Sun, Nov 16, 2003 at 03:46:26PM -0500, Jim Jagielski wrote:
Why 1.4? What will 1.4 have that 1.3 does not? Or do you mean
reopening 1.3 implies that it becomes 1.4?
Only semantics. .4 is even, so stable; .5 is
--On Sunday, November 16, 2003 5:20 PM -0400 Marc G. Fournier
[EMAIL PROTECTED] wrote:
On FreeBSD 4.X it is broken(and will be forever?). On FreeBSD 5.X, use KSE
threading (which may become the default in the future 5.2 release anyways?)
and it works great. man libmap.conf on a FreeBSD box for
Glenn wrote:
On Sun, Nov 16, 2003 at 03:37:19PM -0500, Jim Jagielski wrote:
Oh, how about my (effectively) 2-line patch which adds vhost
to the error log, which I have posted to this list NO LESS THAN 6 TIMES
and spaced out over the past 6 MONTHS in three different formats, using
a global,
On Sun, Nov 16, 2003 at 03:54:59PM -0500, Jim Jagielski wrote:
I'm also curious about what a 1.4/1.5 would do that the current 1.3
does not which would provide a seamless upgrade. Are you talking
API or what? As someone who's preformed numerous such migrations,
the actual mechanics of doing so
On Mon, Nov 17, 2003 at 09:35:20AM +1100, Ian Holsman wrote:
Glenn wrote:
I have some different ideas. One is to distribute APR with 1.3 so
that modules developers could incrementally move their modules to APR.
why can't you just link APR into your 1.3 module? I don't think there
would be
At 01:45 PM 11/14/2003, Sander Striker wrote:
On Thu, 2003-11-13 at 09:06, Jeff Trawick wrote:
Aaron Bannert wrote:
On Tue, Nov 11, 2003 at 09:55:24AM -0700, Brad Nicholes wrote:
Just to point out the obvious fact that hopefully everybody can agree with and
consider taking action on:
On Sun, 16 Nov 2003, Marc Slemko wrote:
3. Threading issues. This is a red herring; threading issues can be a
reason why moving to 2.0 wouldn't give someone enough of a reason to make
it worthwhile, but they do not block anyone moving to 2.0. if they
don't want to use threads, they don't
I've updated the tools/release.sh script in the httpd-dist CVS
repository to make it easier for anyone to create HTTPD tarballs.
Before it was necessary for a tag to exist before a tarball could
be created. This made it very difficult to release
experimental/developmental tarballs to a set of
If Sander hadn't gone awol this wouldn't be so fubar. Any comments?
ap_server_state_t {
enum {AP_STARTING, AP_STARTED, AP_STOPPING} state;
enum {AP_FIRST_START, AP_SUBSEQUENT_START} start_type; /* if AP_STARTING */
enum {AP_GRACEFUL_STOP, AP_HARD_STOP} stop_type; /* if
Glenn wrote:
On Mon, Nov 17, 2003 at 09:35:20AM +1100, Ian Holsman wrote:
Glenn wrote:
I have some different ideas. One is to distribute APR with 1.3 so
that modules developers could incrementally move their modules to APR.
why can't you just link APR into your 1.3 module? I don't think there
I've made some tarballs of the httpd-2.1 tree. I just pulled HEAD of
both httpd and apr (as of about an hour ago, just before greg's pollset
changes). They're here:
http://www.apache.org/~aaron/httpd-2.1.0-rc1/
This seems to work fine on my Mac OS X (10.3 Panther) box, my linux
2.4 x86 box, and
Rasmus Lerdorf wrote:
I have always had the feeling that Apache2+prefork was a bit of a
second-class citizen. I have tested it periodically over the past 2 years
and it has never gotten anywhere close to Apache1 in performance. I ran
another test of 1.3.29 vs 2.0.48-prefork just now just to
What would 1.4 have or be for that to happen?
You have 12 million users - shouldn't be hard to simply ask them what they
would like to see.
Give the customer what he wants and he will be back for more. HTTP ain't
finished yet, plenty of room for some serious improvement.
And I'd also be
* Ben Collins-Sussman [EMAIL PROTECTED] wrote:
FWIW: in the Subversion project, we've assigned the hat of patch
manager to a volunteer in the community. He watches patches come in.
If any patch goes unanswered for a week or more, the patch manager files
it in the issuetracker. No more
Peter J. Cranstone wrote:
What would 1.4 have or be for that to happen?
You have 12 million users - shouldn't be hard to simply ask them what they
would like to see.
Postal fees will be hell...
--
===
Jim
hehe postal fees
why dont we do something like what openoffice does and have people registar
there copys just so we can figure out demographics and such kind of like
what netcraft does
-Kyle
- Original Message -
From: Jim Jagielski [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday,
On Mon, 17 Nov 2003, Ian Holsman wrote:
I belive 2.0 beats 1.3 on these metrics, but like everyone here, Ihave
no more energy proving/disproving which is faster.. 2.0 works for me,
and thats all I really care about, not who else is using it.
Do you really believe this to be true for
On Sun, 2003-11-16 at 15:03, Aaron Bannert wrote:
I've updated the tools/release.sh script in the httpd-dist CVS
repository to make it easier for anyone to create HTTPD tarballs.
Before it was necessary for a tag to exist before a tarball could
be created. This made it very difficult to
Peter J. Cranstone wrote:
In today's environment it's all about 2 words - price/performance. Show me
that Apache 2.x can outperform 1.x by a factor 10 on the same box.
Dig around... I posted a benchmark to this list early in 2.0 development showing a 10x improvement of threaded
2.0 over 1.3 on
-1. I'm still of the mind that _every_ release should be recreatable.
Anything we put out there is going to be at least perceived as
official,
and we should take that into account.
Every release is tagged. A tarball is not a release. Nothing is a
release until AFTER the associated tarball has
The Enums look great, can we extend apr_query_mpm instead though?
Bill
At 05:17 PM 11/16/2003, Jeff Trawick wrote:
If Sander hadn't gone awol this wouldn't be so fubar. Any comments?
ap_server_state_t {
enum {AP_STARTING, AP_STARTED, AP_STOPPING} state;
enum {AP_FIRST_START,
Marc Slemko [EMAIL PROTECTED] wrote:
3. Threading issues. This is a red herring; threading issues can be a
reason why moving to 2.0 wouldn't give someone enough of a reason to make
it worthwhile, but they do not block anyone moving to 2.0. if they
don't want to use threads, they don't have to
On Sun, 2003-11-16 at 17:15, Roy T. Fielding wrote:
-1. I'm still of the mind that _every_ release should be recreatable.
Anything we put out there is going to be at least perceived as
official,
and we should take that into account.
Every release is tagged.
That's what I'm argueing.
On Sun, 2003-11-16 at 15:36, Aaron Bannert wrote:
I've made some tarballs of the httpd-2.1 tree. I just pulled HEAD of
both httpd and apr (as of about an hour ago, just before greg's pollset
changes). They're here:
http://www.apache.org/~aaron/httpd-2.1.0-rc1/
Ok, I'll leave you to the RM
On Sun, Nov 16, 2003 at 02:34:47PM -0800, Justin Erenkrantz wrote:
--On Sunday, November 16, 2003 5:20 PM -0400 Marc G. Fournier
'k, maybe expand the comment in the INSTALL file to address this?
Well, we've asked for confirmation of FreeBSD threading 'working' on the
[EMAIL PROTECTED] -
On Sat, Nov 15, 2003 at 05:20:33PM -0800, Sander Striker wrote:
On Sun, 2003-11-16 at 15:36, Aaron Bannert wrote:
I've made some tarballs of the httpd-2.1 tree. I just pulled HEAD of
both httpd and apr (as of about an hour ago, just before greg's pollset
changes). They're here:
So your basically saying that we retag a release candidate tag with the
final release tagname, when a tarball rolled from such a tag receives
three +1s for release?
I am saying that the contents of a release tarball must match the tag
of that release in cvs. How that happens will depend on the
On Sun, 16 Nov 2003 17:15:35 -0800, Roy T. Fielding wrote
-1. I'm still of the mind that _every_ release should be recreatable.
Anything we put out there is going to be at least perceived as
official,
and we should take that into account.
Every release is tagged. A tarball is not a
Yup, this is what I tend to see ...
One question, what does 'ps auxwl' show, primarily the WCHAN column?
On Sun, 16 Nov 2003, Aaron Bannert wrote:
On Sun, Nov 16, 2003 at 02:34:47PM -0800, Justin Erenkrantz wrote:
--On Sunday, November 16, 2003 5:20 PM -0400 Marc G. Fournier
'k, maybe
On Sun, 16 Nov 2003 18:45:25 -0700
Paul Querna [EMAIL PROTECTED] wrote:
On Sun, 16 Nov 2003 17:15:35 -0800, Roy T. Fielding wrote
-1. I'm still of the mind that _every_ release should be
recreatable.
Anything we put out there is going to be at least perceived as
official,
and we should take
On Sun, Nov 16, 2003 at 09:43:03PM -0400, Marc G. Fournier wrote:
Yup, this is what I tend to see ...
One question, what does 'ps auxwl' show, primarily the WCHAN column?
I don't have access to the machine right now, but I can check later.
-aaron
* [EMAIL PROTECTED] wrote:
Unless anyone strenuously objects, I'm adding back the comments
regarding ScriptInterpreterSource. We're getting an increasing number of
questions about this.
I'm -0 on it, because using ScriptInterpretersource registry without further
explanation of the flaws
* Paul Querna [EMAIL PROTECTED] wrote:
On Sun, 16 Nov 2003 17:15:35 -0800, Roy T. Fielding wrote
-1. I'm still of the mind that _every_ release should be recreatable.
Anything we put out there is going to be at least perceived as
official,
and we should take that into account.
65 matches
Mail list logo
