river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: ServiceDiscoveryManager test coverage
Date Wed, 01 Sep 2010 11:34:18 GMT
Well I must say the recent participation is very encouraging, this 
project had a record number of emails to the development mailing list 
last month, but I don't come from a Programming background, I'm not an 
expert and don't have any merging experience.

Therefore in this case I'd prefer to observe rather than vote for any 
particular methodology or risk letting my own wants or ego stand in the 
way of what River needs, which is increasing participation and innovation.

I have no objections to you reverting the changes.

I expect that you'll continue participating and perhaps blaze the trail 
as leading developers, so that I can watch and learn, I'm interested to 
see what you have in mind.

River needs people willing to do the leg work necessary to succeed.

Best Regards,

Peter.

Jonathan Costers wrote:
> I have to agree with Sim here ...
>
> I'd say (if it were entirely up to me):
> 1. backout the changes
> 2. make sure the current QA tests run
> 3. add categories servicediscovery,discoveryservice,io and security to the
> QA test categories to run by Hudson, one by one
> 4. make sure these QA tests run as well
> 5. piece by piece, restore the changes and keep an eye on any tests failing.
> In parallel, keep validating and adding more QA test categories.
>
> This would allow us to work in a more structured manner, and to perform peer
> reviews on bite size changes.
> We have to better organize ourselves, considering the limited resources we
> have.
>
> To summarize:
> - the changes to RemoteEvent etc. caused many discovery related tests to
> fail
> - the changes to ClassLoading caused some classloading / io related tests to
> fail
> - the changes to DynamicPolicyProvider caused security (and other) tests to
> fail
>
> And that's what I found after going through it very quickly and backing out
> some obvious things.
> These actually look more like experiments than actual tested changes.
> IMO, this kind of experimentation should probably be done in a skunk branch,
> not the trunk.
>
> If for any reason, my understanding is incorrect, and backing out is not an
> option, then I would suggest to at least create a JIRA issue for each of the
> above topics.
>
> Thanks
> Jonathan
>
> 2010/9/1 Peter Firmstone <jini@zeus.net.au>
>
>   
>> Sim IJskes - QCG wrote:
>>
>>     
>>> On 09/01/2010 01:16 AM, Jonathan Costers wrote:
>>>
>>>       
>>>> Similarly, having backed out the RemoteEvent changes, and running the
>>>> "discoveryservice" category:
>>>>
>>>>         
>>> It looks to me, that the code in the trunk was not completely ready.
>>>
>>>       
>> It looks that way.
>>
>>
>>  Would it be a good idea to revert the changes until the unit tests run
>>     
>>> again, and build a branch in svn to continue the work?
>>>
>>>       
>> Let me get my head around understanding the failures first before we
>> revert.
>>
>>
>>
>>
>>     
>>> If a committer (with svn access) needs help, i can offer some assistance.
>>>
>>>       
>> Thanks ;) much appreciated.
>>
>>     
>>> Gr. Sim
>>>
>>>
>>>
>>>       
>
>   


Mime
View raw message