> 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.
> 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.
> 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.
> 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.
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 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.)
- Rod
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.
