Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-ID: <3C866C2D.1080208@cnet.com>
Date: Wed, 06 Mar 2002 11:21:17 -0800
From: Brian Pane <brian.pane@cnet.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:0.9.8) Gecko/20020204
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: cvs commit: httpd-2.0/include ap_release.h
References: <028901c1c53b$102de4b0$7f00000a@KOJ>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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