commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject RE: [VOTE] Moving Proxy to Commons Proper
Date Sat, 22 Oct 2005 12:20:50 GMT
On Sat, 2005-10-15 at 07:33 -0400, James Carman wrote:
> Robert,

hi james

> Thank you for your feedback (finally somebody said *something*).  I made
> this a vote based on the instructions found at
>  Maybe
> we should update that WIKI to suggest making a proposal first and then
> starting a vote if there are no objections.  

feel free to change the wiki: people can revert or modify anything they
don't like. 

> I really just wanted to know if
> there were any technical objections to having proxy move into the commons
> proper so that I could fix the problems.  I would really like to see this
> become a full-fledged commons component.  I think it's a very useful idea
> and a pretty intuitive API.

no criticism intended: it's just that VOTE threads tend to get a bit
messy if people pick up on the issues too late. it's a bit of a
judgement call and PROPOSAL's aren't always necessary. 

> As for your suggestion to cut a release candidate now, I like it.  I do
> think that I need some simple tutorials/examples on the site before it's
> ready for a real release, so I'll try to take care of that sometime soon.
> Then, I'll cut a release candidate, per your suggestion.  I will try to
> follow the directions found at
> to prepare the
> release candidate, but I'm probably bound to make mistakes as I'm new to
> this project management stuff.  I'll probably have a few questions along the
> way too! 

that's why creating a sample release candidate is a good idea. the notes
have been developed over many years and are pretty comprehensive now. i
hope you'll continue the tradition of improving the documentation as you
learn how to cut a commons release. 

> Also, I would still like to hear if anyone else has any suggestions for
> things that I need to take care of before they would consider it ready for
> release.  Resolving the 1.5 dependency helped of course, even if it did make
> the API a lot uglier IMHO.  I liked the var-args feature for specifying the
> interfaces/classes that the proxy should support and I would rather use the
> core JDK Executor class rather than the one from the "concurrent" API.  Oh
> well.

folks have picked this up on the other thread

- robert

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message