You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by Ryan Bloom <rb...@covalent.net> on 2002/03/06 18:48:38 UTC
RE: cvs commit: httpd-2.0/include ap_release.h
>
> Modified: . CHANGES
> include ap_release.h
> Log:
> bump after the tag.
Yes, I have tagged 2.0.33. I won't roll the release until Aaron commits
the path problem fix. I'll announce when the roll is done.
Ryan
RE: cvs commit: httpd-2.0/include ap_release.h
Posted by Sander Striker <st...@apache.org>.
> From: Brian Pane [mailto:bpane@pacbell.net]
> Sent: 06 March 2002 19:35
> Justin Erenkrantz wrote:
>
> >On Wed, Mar 06, 2002 at 09:48:38AM -0800, Ryan Bloom wrote:
> >
> >>Yes, I have tagged 2.0.33. I won't roll the release until Aaron commits
> >>the path problem fix. I'll announce when the roll is done.
> >>
> >
> >Let me just go on record saying that I don't think we're in a
> >position to release another version.
> >
> >IMHO, we need the API changes in before doing another release.
> >You obviously don't seem to agree with me (per our usual custom).
> >Whatever. I believe this isn't a good time to be tagging. We've
> >just had several major changes and we still haven't thoroughly
> >tested their impact yet.
>
> I agree with Justin on both parts: I'd prefer to get the API
> changes in place (pool allocators and buckets are the ones that
> I know of) and do some more testing on the latest round of filter
> rewrites (are they running on daedalus) before relasing 2.0.33.
Yes, I have to agree with this too. I didn't see a tag comming at
this point. And with the little amount of time we had to test
the new code, I don't have the confidence in 2.0.33 as I had
in 2.0.32.
> I'd ideally like to see 2.0.33 become the "API freeze" release,
> where we're able to tell 3rd party module maintainers that the
> APIs are now stable, with 2.0.34 following it as the "performance
> tuning and bug fixes" release (and GA candidate).
>
> --Brian
Sander
Re: cvs commit: httpd-2.0/include ap_release.h
Posted by Brian Pane <br...@cnet.com>.
Ryan Bloom wrote:
>>Justin Erenkrantz wrote:
>>
>>>On Wed, Mar 06, 2002 at 09:48:38AM -0800, Ryan Bloom wrote:
>>>
>>>>Yes, I have tagged 2.0.33. I won't roll the release until Aaron
>>>>
>commits
>
>>>>the path problem fix. I'll announce when the roll is done.
>>>>
>>>Let me just go on record saying that I don't think we're in a
>>>position to release another version.
>>>
>>>IMHO, we need the API changes in before doing another release.
>>>You obviously don't seem to agree with me (per our usual custom).
>>>Whatever. I believe this isn't a good time to be tagging. We've
>>>just had several major changes and we still haven't thoroughly
>>>tested their impact yet.
>>>
>>I agree with Justin on both parts: I'd prefer to get the API
>>changes in place (pool allocators and buckets are the ones that
>>I know of) and do some more testing on the latest round of filter
>>rewrites (are they running on daedalus) before relasing 2.0.33.
>>
>>I'd ideally like to see 2.0.33 become the "API freeze" release,
>>where we're able to tell 3rd party module maintainers that the
>>APIs are now stable, with 2.0.34 following it as the "performance
>>tuning and bug fixes" release (and GA candidate).
>>
>
>I'm sorry. I'm confused. It seems like we are willing to make SOME
>major changes if some people on this list are interested in them. But
>other major changes are a bad idea, even if they fix bugs.
>
>Please, somebody explain to me which changes are allowed to go into the
>code, and which aren't?
>
For me, the two distinguishing factors are:
* "Planned, widely communicated changes" vs. "surprises"
The bucket free list stuff is a big change, in terms of
the size of the diffs. But it's been widely communicated
among the developers for the past couple of quarters and has
been documented in STATUS for a long time. And Cliff has
made the patches available in advance so that people can test
and fix them before such a big change is checked into CVS.
That makes life a lot easier for anybody who needs to take
a snapshot of the tree for use in their work. In contrast,
the "hey, I think I'll redesign the core filter handling and
check it into the tree tonight, and get the resulting bugs
fixed up over the next couple of weeks" type of changes tend
to make life unpleasant for the other developers.
* "Changes with a large cost impact for users" vs. "changes without
a large cost impact for users"
The API changes currently planned in STATUS will enable us to
fix a major scalability problem (calling malloc way too much).
If we do this successfully, 2.0 will yield a hardware cost savings
for users running large sites. If we don't, it will yield an
increase in hardware costs relative to 1.3, due to the extra
CPU cycles needed for all the mallocs. (BTW, I'm delaying my
other big performance-related ideas until after 2.0 GA (like doing
a leader/follower version of worker), because: 1) their benefits
will be small in comparison to the bucket freelist change, and
2) they can be done without API changes, so adding them post-GA
won't break backward compatibility.)
--Brian
RE: cvs commit: httpd-2.0/include ap_release.h
Posted by Dale Ghent <da...@elemental.org>.
On Wed, 6 Mar 2002, Ryan Bloom wrote:
| I realize that this is a VERY sarcastic message. I am seriously trying
| to make a point here. Either we are developers all pulling towards a
| real release, or we aren't. I believe that we are.
This was my point during the past email thread re: release. Yes, I think
there's not one person here who does not want to GA ap 2.0. But to claim
that the developers 'are pulling towards a real release' is unbelieveable.
Not one ASF member seems to have an inkling of a clue as to when 2.0 will
be GA'd. In fact, I doubt anyone had an idea .33 would be tagged when it
was.
You guys are dangling a carrot in front of yourselves, while claiming
you're all making progress towards it. Open-source stances and cruft
aside, some real release management and archetecture roadmap needs to be
put in place... or 2.0 will be surely featured in Wired's next vaporware
article, which honestly would be really unfortunate.
/dale
RE: cvs commit: httpd-2.0/include ap_release.h
Posted by Ryan Bloom <rb...@covalent.net>.
> Justin Erenkrantz wrote:
>
> >On Wed, Mar 06, 2002 at 09:48:38AM -0800, Ryan Bloom wrote:
> >
> >>Yes, I have tagged 2.0.33. I won't roll the release until Aaron
commits
> >>the path problem fix. I'll announce when the roll is done.
> >>
> >
> >Let me just go on record saying that I don't think we're in a
> >position to release another version.
> >
> >IMHO, we need the API changes in before doing another release.
> >You obviously don't seem to agree with me (per our usual custom).
> >Whatever. I believe this isn't a good time to be tagging. We've
> >just had several major changes and we still haven't thoroughly
> >tested their impact yet.
> >
>
> I agree with Justin on both parts: I'd prefer to get the API
> changes in place (pool allocators and buckets are the ones that
> I know of) and do some more testing on the latest round of filter
> rewrites (are they running on daedalus) before relasing 2.0.33.
>
> I'd ideally like to see 2.0.33 become the "API freeze" release,
> where we're able to tell 3rd party module maintainers that the
> APIs are now stable, with 2.0.34 following it as the "performance
> tuning and bug fixes" release (and GA candidate).
I'm sorry. I'm confused. It seems like we are willing to make SOME
major changes if some people on this list are interested in them. But
other major changes are a bad idea, even if they fix bugs.
Please, somebody explain to me which changes are allowed to go into the
code, and which aren't?
I have been seeing messages that say we absolutely get a GA release ASAP
and others that say that a GA release must wait until the API's have
frozen. Of course, by definition, we don't freeze API's in Apache. For
all intents and purposes, we have been stating that the API's have been
frozen for some time in fact.
So, could somebody explain which code is allowed to change, and which
code isn't?
I realize that this is a VERY sarcastic message. I am seriously trying
to make a point here. Either we are developers all pulling towards a
real release, or we aren't. I believe that we are. Tagging the tree
today doesn't actually hurt anything it just draws another line and
says, this code is good. I believe the code is good. It will be better
by the time I actually roll the release.
Ryan
Re: cvs commit: httpd-2.0/include ap_release.h
Posted by Brian Pane <bp...@pacbell.net>.
Justin Erenkrantz wrote:
>On Wed, Mar 06, 2002 at 09:48:38AM -0800, Ryan Bloom wrote:
>
>>Yes, I have tagged 2.0.33. I won't roll the release until Aaron commits
>>the path problem fix. I'll announce when the roll is done.
>>
>
>Let me just go on record saying that I don't think we're in a
>position to release another version.
>
>IMHO, we need the API changes in before doing another release.
>You obviously don't seem to agree with me (per our usual custom).
>Whatever. I believe this isn't a good time to be tagging. We've
>just had several major changes and we still haven't thoroughly
>tested their impact yet.
>
I agree with Justin on both parts: I'd prefer to get the API
changes in place (pool allocators and buckets are the ones that
I know of) and do some more testing on the latest round of filter
rewrites (are they running on daedalus) before relasing 2.0.33.
I'd ideally like to see 2.0.33 become the "API freeze" release,
where we're able to tell 3rd party module maintainers that the
APIs are now stable, with 2.0.34 following it as the "performance
tuning and bug fixes" release (and GA candidate).
--Brian
RE: cvs commit: httpd-2.0/include ap_release.h
Posted by Ryan Bloom <rb...@covalent.net>.
> Greg Stein wrote:
>
> > As Ryan pointed out, there is no such thing as...
> >
> > Cheers,
> > -g
>
>
> You two agreeing on so many things is starting to worry me. It can
*only*
>
> be a sign of the end times. :)
I actually just sent a message to Greg saying that same thing. :-)
Ryan
Re: cvs commit: httpd-2.0/include ap_release.h
Posted by "Paul J. Reder" <re...@remulak.net>.
Greg Stein wrote:
> As Ryan pointed out, there is no such thing as...
>
> Cheers,
> -g
You two agreeing on so many things is starting to worry me. It can *only*
be a sign of the end times. :)
--
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein
Re: cvs commit: httpd-2.0/include ap_release.h
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Mar 06, 2002 at 10:20:05AM -0800, Justin Erenkrantz wrote:
>...
> Let me just go on record saying that I don't think we're in a
> position to release another version.
Of course we are. Call it an alpha. If you don't even think that is fine,
then call it a developer snapshot.
>...
> I won't be voting on any 2.0.33 releases or rather I will be
> casting a negative vote because I don't want another public
You mean that you won't vote to call it beta. But Ryan can easily post a
"developer" release called 2.0.33 for people. A number of users can't get
the stuff out of CVS, so the tarballs are very good for them.
> release without our API changes (both of which have been posted).
> That obviously won't stop the release if the majority agrees
> with you. -- justin
As Ryan pointed out, there is no such thing as a true API freeze. And trying
to establish a "hard freeze" isn't going to work. There are quite a few
things that people might want to change, but just haven't had time to get
to. A freeze is effectively a smackdown for those people, a little slap
against their lack of time. It isn't right, and it isn't good for the code.
If an API is wrong, or it doesn't lead to a great server, then it needs to
change, and it *will* get changed.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
RE: cvs commit: httpd-2.0/include ap_release.h
Posted by Allan Edwards <ak...@meepzor.com>.
> Let me just go on record saying that I don't think we're in a
> position to release another version.
I'll second that based on problems I still see
with filters - additional post coming momentarily.
Allan
Re: cvs commit: httpd-2.0/include ap_release.h
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Wed, Mar 06, 2002 at 09:48:38AM -0800, Ryan Bloom wrote:
> Yes, I have tagged 2.0.33. I won't roll the release until Aaron commits
> the path problem fix. I'll announce when the roll is done.
Let me just go on record saying that I don't think we're in a
position to release another version.
IMHO, we need the API changes in before doing another release.
You obviously don't seem to agree with me (per our usual custom).
Whatever. I believe this isn't a good time to be tagging. We've
just had several major changes and we still haven't thoroughly
tested their impact yet.
I won't be voting on any 2.0.33 releases or rather I will be
casting a negative vote because I don't want another public
release without our API changes (both of which have been posted).
That obviously won't stop the release if the majority agrees
with you. -- justin