Re: [pool] pool: the future [WAS Re: [pool] synchronization issues in Pool]
On Sat, 2005-10-29 at 12:49 -0400, Sandy McArthur wrote: Since you mentioned not breaking backwards compatibility I started working on a fresh implementation which I think is coming along very well and I intend to contribute back to the commons. sounds good moving to 2.0 gives a little more freedom but even so it makes sense to preserve as much compatibility as possible. I've uploaded JavaDocs of what progress I've made so far. I figure I'm about 45% done not including unit tests. See the org.mcarthur. package: JavaDocs for only the public interface: http://sandy.mcarthur.org/pool/Pool-Protected/ JavaDocs including private members: http://sandy.mcarthur.org/pool/Pool-Private/ since there's substantial code and it's being developed elsewhere (rather than on list here), they'll be some paperwork required. the incubator projects acts as the contact point for this kind of thing. i'll make some enquiries about the process. (the ASF is currently trying to grow the new processes required to scale. things are a little chaotic, under-development and under-documented at the moment so patience may be required.) ASF code is used extensively and it's very important that we can demonstrate it's origins. I am interested in becoming a commiter someday. cool the ASF can be a bit mysterious (when viewed from the outside) at times. few rules but lots of social conventions. if you get a minute or two, browse the foundation sites (http://www.apache.org and http://www.apache.org/dev) as well as jakarta. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[pool] pool: the future [WAS Re: [pool] synchronization issues in Pool]
On Thu, 2005-10-27 at 21:05 +0100, robert burrell donkin wrote: On Mon, 2005-10-24 at 17:42 -0400, Sandy McArthur wrote: snip While I'm at it would it be desirable to transition to the privately head lock idiom it might (however) stop a user doing something equivalent through carelessness or naivity. so probably worth doing. would need to add a note to the documentation since this would change the semantics. opinions? I have a number of pending patches: http://tinyurl.com/cauwd that I'd like to see commited or rejected as I'm starting to feel no one cares about them and it's becoming a pain to maintain my own patched pool version. most of the committers listed in the project.xml aren't that active in the commons any more :-/ re: 33264, 36719, 36904, 37153 these all suffer from issues with backward compatibility. i'd like to have a little think and then move the discussion to a new thread. there are a couple of issues which i needed a bit of time to think about. IMHO these changes will improve pool (though some details need more discussion) but are not backwards compatible with the existing 1.x releases. so, if these are applied pool would need to be moved forward to 2.0. moving to 2.0 open doors for other revisions. the recent synchronization fixes are important so one more 1.x release would also be needed. i created a new branch from trunk (before committing the above patches). the trunk version is now 2.0-dev. all of these patches (save the collections one) have now been committed. i've haven't committed the collections patch since i wonder whether it might be better to break the dependency entirely. as always, opinions encouraged :) a more significant issue is that pool really seems short of an active development community. there are patches from developers out there and the existing committers haven't been very active for a while. so, perhaps all that's needed is an effort to restart active development. i'm stretched pretty thin already. so, i'd need some help from developers to kick start pool developmen. this might lead to 1.3 and 2.0 releases. any volunteers interested? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pool] pool: the future [WAS Re: [pool] synchronization issues in Pool]
Since you mentioned not breaking backwards compatibility I started working on a fresh implementation which I think is coming along very well and I intend to contribute back to the commons. I've uploaded JavaDocs of what progress I've made so far. I figure I'm about 45% done not including unit tests. See the org.mcarthur. package: JavaDocs for only the public interface: http://sandy.mcarthur.org/pool/Pool-Protected/ JavaDocs including private members: http://sandy.mcarthur.org/pool/Pool-Private/ I am interested in becoming a commiter someday. On 10/29/05, robert burrell donkin [EMAIL PROTECTED] wrote: re: 33264, 36719, 36904, 37153 these all suffer from issues with backward compatibility. i'd like to have a little think and then move the discussion to a new thread. there are a couple of issues which i needed a bit of time to think about. IMHO these changes will improve pool (though some details need more discussion) but are not backwards compatible with the existing 1.x releases. so, if these are applied pool would need to be moved forward to 2.0. moving to 2.0 open doors for other revisions. the recent synchronization fixes are important so one more 1.x release would also be needed. i created a new branch from trunk (before committing the above patches). the trunk version is now 2.0-dev. all of these patches (save the collections one) have now been committed. i've haven't committed the collections patch since i wonder whether it might be better to break the dependency entirely. as always, opinions encouraged :) a more significant issue is that pool really seems short of an active development community. there are patches from developers out there and the existing committers haven't been very active for a while. so, perhaps all that's needed is an effort to restart active development. i'm stretched pretty thin already. so, i'd need some help from developers to kick start pool developmen. this might lead to 1.3 and 2.0 releases. any volunteers interested? -- Sandy McArthur Government big enough to supply everything you need is big enough to take everything you have ... The course of history shows that as a government grows, liberty decreases. -- Thomas Jefferson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
