No harm done here...
I asked for commit access (see thread "Commit access ?")
but wasn't sure if an actual vote was needed or it was only a permission
problem.
I'll just call for a formal vote
There are some other points that worry me more in your mail...
> We should certainly be sensitive to the needs of the "donating"
> project, but perhaps no more so than any other "customer" of the
> component--within Apache/Jakarta and beyond.
What you have to consider is that we are already using the component and
the auto-build procedure takes the latest version that's why we have a
stong dependency. If you don't consider the slide build, half of the
time it will fail and we have to maintain our own copy of the httpclient
code and sync every couple of months. (but I think we don't want that,
but then again that is what you normally do with external libraries).
Changing the logging was a big change because the logging was the main
reason (for me) of working on the command line client, it's a way to
debug/test server configurations.
> As with all open source development, when you "release" a project to
> the community, you gain some things, like having a larger group of
> developers test, document, fix, maintain and enhance that project (and
> projects that may interoperate with it). But you also lose some
> things, namely a bit of control over the evolution of that precise
> code base. You're always free to try to push that evolution in one
> direction or another, or (under the Apache license at least) to fork
> it off and do whatever you want with your forked version of the code.
> But you've lost the ability to directly control that evolution without
> gaining some sort of consensus with the larger community. (You may
> lead but they don't have to follow.)
I don't like that log glue but I can/must live with it because I must
admit I didn't follow the commons list so I didn't see the discussion
about it. But from now on I'll follow it more closely.
> Absolutely. And I'd argue that the process is working precisely as it
> should here. It was unwitting, but even if it wasn't, didn't this
> happen exactly the way it should? We deprecated a method or two. Dirk
> spoke up and said "wait, don't deprecate that, I need it for X", and
> now we're (Dirk too) working to find a way to support that.
and I'm sure we will find a solution...
> (Note also that this particular component isn't yet at a 1.0 release,
> so it shouldn't be too surprising for it to change from time to time.
> If it needs to "change back" for some reason, it can and certainly
> should do that.)
I totally disagree with this, for me the HttpClient is / should be a
stable component.
The version that was delivered with slide 1.0.6 was already stable and
is being used in private projects.
I have already made a website management swing gui on top of it and I'm
now working on another one.
So far Slide is very stable for me, some features are missing and there
is sometimes a small bug but overall it's been a stable development.
Each following version was better than the previous, I hope I can expect
the same from HttpClient.
> > this situation illustrates one of the social issues we
> > need to be sensitive about when migrating packages out
> > of other projects and into the commons.
> I think your concern here is valid. This is a critical (in the sense
> of "important") interaction, and one that we'd do well to handle
> carefully. But it seems to me that this is a healthy process.
I must admit I was surprised to read that you didn’t know me (you
obviously don’t follow the slide dev list). But you were correct to say
you wanted a formal vote to give me commit access.
Again no hard feelings...
Regards
Dirk
