Mailing-List: contact commons-httpclient-dev-help@jakarta.apache.org;
 run by ezmlm
Precedence: bulk
Reply-To: "Commons HttpClient Project"
 <commons-httpclient-dev@jakarta.apache.org>
Mime-Version: 1.0 (Apple Message framework v612)
In-Reply-To: <401E5661.1090802@tibco.com>
References: <F4211B7A-546E-11D8-8CF9-00306557E112@u.washington.edu>
 <401E5661.1090802@tibco.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <77E98AF4-558A-11D8-93DB-00306557E112@u.washington.edu>
Content-Transfer-Encoding: 7bit
From: Michael Becke <becke@u.washington.edu>
Subject: Re: Promote HttpClient out of commons?
Date: Mon, 2 Feb 2004 09:17:01 -0500
To: "Commons HttpClient Project" <commons-httpclient-dev@jakarta.apache.org>

Eric,

These are good questions, and I think they summarize well the current 
discussion.

> Should HttpClient be promoted to a Jakarta project?
> - Yes, that would seem to make sense, given the separate mailing list, 
> the list of other "commons" libraries it depends upon, the separate 
> mailing list, and the bugzilla needs, which all point to its slightly 
> "heavier" nature than other commons projects.

At this point I would agree.  It seems very likely that we will move in 
this direction.  Arguments to the contrary are still welcome though.

> Should HttpClient be a TLP?
> - Don't think so.  Too much extra infrastructure, not much extra 
> benefit.

Though moving to a TLP sounds exciting, I agree that it may be too much 
now.  In particular I think that HttpClient is not quite mature enough 
for this status.  Also, I do not think the developer community is quite 
large enough to support this yet either.

Becoming a TLP could be a long term goal.  As others have mentioned 
there are certainly possible HttpClient sub-projects (WebDAV, Gnutella, 
Http Cache).


> When can HttpClient 2.0 ship?
> - Although I think Oleg is being diligent in wanting to have a 
> road-map in place for shipping 2.0, the contrary point is that as 
> open-source software, the road-map is dependent on the interests that 
> drive the product forward.  As such, it is entirely unpredictable. I 
> would like to see/hear Oleg's ideas about where we should be going, 
> since his ideas will probably be quite helpful to the rest of us, but 
> I'm not sure we need to hold up the 2.0 release for that.  Email or a 
> web-site posting would work just as well for that.

Hopefully soon.  A road map would be good, but I think we still need to 
debate if we want to hold up 2.0 before it's done.

> - I seem to recall that a bug was actually reported against 2.0rc3, 
> which means that we need to have a 2.0rc4, doesn't it?  I think we 
> should be absolutely ruthless, that if a bug is not reported within 
> the appropriate window, we should name whichever rcX release the 
> final.  If need be, we can always come up with a 2.0.1 release that 
> patches any future discovered bugs.

I could be wrong here, but I do not think a rc4 is required, unless we 
would like one.  I also prefer a 2.0 sooner, and a 2.0.1 if necessary.

Mike


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org