> > I'm sorry, but if there are indeed important issues
> > left to fix, I didn't see any report which would
> > indicate that this is indeed the case.
>
> So here's a perfect example of what I'm talking about:
>
> I started to add additional JUnit unit tests, and found a bug with the
first
> test I added.
>
> The org.apache.commons.httpclient.Base64.decode(byte[]) method doesn't
work
> properly for 2/3rds of all valid inputs, since it translates the trailing
> '=' pads into null characters. This means
> Base64.decode(Base64.encode(data)) is not equal to data whenever
data.length
> % 3 != 0. Is it critical? Well, I would bet that it is never used within
> the httpclient package itself, but as a public method of a public class, I
> would suggest that it either work, that the deviation from the expected
> behavior be clearly indicated, or that it not be there. Anything less is
a
> disservice to the end-user base and the Apache community.
The same class is used in Tomcat and Slide too. The class was originally
copied from Xerces.
The decode method is used to decode BASIC passwords, and it worked ok for
us. If it has a bug, then we have a lot of copies of the file to update, but
however it makes absolutely no sense to hold a release until that one is
fixed.
> > You should post a list of the issues you
> > want to have fixed before 1.0 is released.
>
> My point is that we haven't adequately tested the full suite of httpclient
> functionality, so we don't even know what issues are lurking out there.
Ok.
> > However, I don't have time to do the issue tracking
> > and other (same goes for the docs mentioned below),
>
> If we don't have time to test and minimally document the component, I
would
> suggest we don't have time to maintain a 1.0 release.
Writing docs + writing tests + spending time doing lots of QA isn't the same
time wise as : type 'ant dist' and upload the results + fix reported bugs.
Actually, the time spent for doing the second thing (which is the minimum
required to make an APache release) is a very small subset of the first
thing.
> > so I would suggest (as you seem to imply) that
> > you volunteer to be the release manager for the
> > version 1.0 of this component.
>
> I'm not sure what "release manager" entails, but I'll certainly volunteer
to
> continue to add additional unit tests and try to put together some basic
> documentation.
>
> > I guess I would end up complaining and vetoing any
> > API change, and that would be bad for the project. Instead,
> > I think the best by far is that I take my log4j-less snapshot
> > of the CVS, and commit it in the Slide repository, so that
> > I have the stable code I need (instead of having to
> > update my code to accommodate API changes).
>
> There is no API change associated with the log4j support. All you need to
do
> is drop the log4j.jar into your classpath, and it sounded like there were
> viable alternatives to that as well. I'm not married to the log4j
> dependency as much as I am "divorced" from the previous System.out
logging.
> If anyone wants to improve it, I should hope they're not avoiding changes
on
> my account.
Ok, fine. Although the current situation is bad, I didn't agree with the
change, and vetoed it (and my position also got some support). However, you
didn't revert the patch as you should have.
> I'm disturbed by the "I give up" tone in that comment. The primary thing
> I'm suggesting is that we sufficiently test and document httpclient before
a
> 1.0 release. I'd also suggest that if changes are warranted, now is the
> time to make tweaks to the API as well, but I don't have anything in
> particular in mind short of removing the deprecated constructors.
I was cautious about putting that project in the commons because of :
- API stability
- spending tons of time in discussions about coding style (and similar
stuff) ;-)
Also, since I need a snapshot of the HTTP client for my project, I'm going
to copy the code. Is there a problem with that ?
> I for one would be disappointed to see you distance yourself from
> commons-httpclient. (But at the same time, I think we have to expect that
> once a code-base is moved into commons it will (and should) evolve
slightly
> differently than it did as part of a specific project. That means the
> process is working, and that the component is growing to meet a variety of
> needs.)
I had hoped the changes would be more limited, at least a version 1.0 was
released.
> PS:
>
> > That basically means that very few OSS projects
> > would ever get released ;-)
>
> I think many of the projects that pass through sourceforge/freshmeat
> demonstrate that we could get by with a lot fewer OSS projects ever being
> released. I'll trade quality for quantity any day.
Apache has higher quality standards (but it can vary from one project to
another). If you don't believe these standards are met by the HTTP client,
then I agree we should wait to release it as 1.0.
Remy
