Re: [DISCUSS] Was: Re: [VOTE] Theory based development

2014-01-22 Thread Dennis Reedy
On Jan 22, 2014, at 657AM, Peter j...@zeus.net.au wrote: Startable only had one purpose: To provide the implementor a thread of execution after construction completes. It's provided by the the infrastructure to the service implementation, what the implementor does with it is their

Re: DISCUSS: Proposal for eliminating tensions; return to collaborative development

2014-01-22 Thread Greg Trasuk
On Jan 21, 2014, at 6:57 AM, Peter Firmstone j...@zeus.net.au wrote: If this proposal is supported, I'd also reccommend that trunk be reverted back to the 2.2 River branch, with the exception of Sim's work on ClassLoading, which should be included. Provided there is support, change

Re: DISCUSS: Proposal for eliminating tensions; return to collaborative development

2014-01-22 Thread Dennis Reedy
On Jan 22, 2014, at 916AM, Greg Trasuk tras...@stratuscom.com wrote: On Jan 21, 2014, at 6:57 AM, Peter Firmstone j...@zeus.net.au wrote: If this proposal is supported, I'd also reccommend that trunk be reverted back to the 2.2 River branch, with the exception of Sim's work on

Re: DISCUSS: Proposal for eliminating tensions; return to collaborative development

2014-01-22 Thread Greg Trasuk
I understand the sentiment, but I’m uncomfortable with the number of changes that happened without much review between releases. Run the following commands: svn diff https://svn.apache.org/repos/asf/river/jtsk/trunk https://svn.apache.org/repos/asf/river/jtsk/branches/2.2 svn diff

Re: [DISCUSS] Was: Re: [VOTE] Theory based development

2014-01-22 Thread Peter
I was more thinking along the lines of encouraging best practise. Right now, if you read River's service implementations, every single one uses final fields and publishes partially constructed service reference to other threads, the hotspot compiller is free to reorder so these, so threads see

Re: DISCUSS: Proposal for eliminating tensions; return to collaborative development

2014-01-22 Thread Peter
Just to clarify, the reversions fixed problems with merging, they were unrelated to tests. When I fix a failing test, I first confirm it also passes on either other architectures or after repeated tests, or that changes made revealing the failure aren't directly related, then I inspect the

Re: DISCUSS: Proposal for eliminating tensions; return to collaborative development

2014-01-22 Thread Peter
Also failure occurs on hudson, that I can't repeat locally, so yes I sometimes perform experiments, but the tests always pass locally before I commit changes. In any case, the code will remain available in qa_refactor after I finish the work, what the community does with it is up to the

Re: DISCUSS: Proposal for eliminating tensions; return to collaborative development

2014-01-22 Thread Peter
Also another clarification, while I'm refactoring, as I am now, replacing TaskManager, I'll submit code that causes test failures, so other people are able to review the development process. In this case I don't modify test code, only the application code until the refactoring work is