Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <40BF0E5C.4080508@attglobal.net>
Date: Thu, 03 Jun 2004 07:41:16 -0400
From: Jeff Trawick <trawick@attglobal.net>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.6) Gecko/20040117
MIME-Version: 1.0
To: dev@apr.apache.org
Subject: Re: documented 1.0 showstoppers
References: <40BEFCF9.8010608@attglobal.net>
 <1086261264.30290.35.camel@localhost>
In-Reply-To: <1086261264.30290.35.camel@localhost>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Paul Querna wrote:
> On Thu, 2004-06-03 at 06:27 -0400, Jeff Trawick wrote:
> 
>>Who is going to do anything about these showstoppers and when?  If no action, I 
>>don't see why they should be considered showstoppers.
>>
> 
> Another Place to Look is Bugzilla:
> http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=&product=APR&keywords=PatchAvailable
> 
> I currently see 17 bugs with PatchAvailable for APR. Surely these should
> be considered out before any 1.0 release is made.

Given the inability thus far to have a 1.0 release, I think we need to be 
extremely conservative about what is considered a showstopper.  Otherwise, it 
may never happen.  There will always be bugs and there will always be fixes 
which aren't yet in a release and hopefully there will eventually be a series 
of releases with most of them better overall than the previous one.  There will 
never be 1.0.1, 1.0.2, etc. if there is never a 1.0.0.  It is only the promise 
of 1.0.1, 1.0.2, etc. which makes apr viable.

IMO, the only thing which should hold up a release is a fix for an API which is 
known to be broken (causes great pain to app developers to change API later, 
but being unable to resolve some issue due to broken API is also nasty) or a 
fix for a critical aspect of the release mechanism (e.g., something hosed with 
version symbols).

w.r.t. "broken API": I mean the interface is broken.  Not a showstopper if the 
implementation is broken but potentially fixable using the current interface.