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: Open discussion on development process
Date Sat, 01 Dec 2012 10:06:27 GMT
Gregg Wonderly wrote:
> I still wonder why it doesn't feel right that the test suite be in the same branch as
the associated "release".  
That was a comment I made, not that it's a pressing concern, right now 
we need to focus on the ability of the harness to deal with concurrent 
code and reducing shared state - shared via protected variables and 
collections.

The qa test suite hasn't had much attention for some time, we're 
experiencing test failures due to concurrency issues.
> Some of the new code needs new test that demonstrate "functionality" while other tests
that demonstrate compatibility will be ran on each release without change.  It seems to me,
that in the end, when a release goes out the door, the tests that validated that release,
are part of that "release".
>   
> If we need two different types of tests, and a migration path from "functionality tests"
into "compatibility tests", then maybe we really need two trees for development of each release,
and branching the whole test suite would be one branch an the new release would be the other.
>
> Is that how you guys are thinking about this?
>   

No not really, we just want to fix and refactor the test suite.
> Gregg Wonderly
>
> On Nov 30, 2012, at 9:43 PM, Peter Firmstone <jini@zeus.net.au> wrote:
>
>   
>> On 30/11/2012 12:27 AM, Dan Creswell wrote:
>>     
>>> On 29 November 2012 13:11, Peter Firmstone<jini@zeus.net.au>  wrote:
>>>
>>>       
>>>> The last passing trunk versions:
>>>>
>>>> Jdk6 Ubuntu     1407017
>>>> Solaris  x86        1373770
>>>> Jdk7 Ubuntu     1379873
>>>> Windows           1373770
>>>>
>>>> Revision 1373770 looks the most stable, I think all platforms were passing
>>>> on this,  1407017 only passed on Ubuntu jdk6, nothing else.
>>>>
>>>> If we can confirm 1373770 as stable, maybe we should branch a release off
>>>> that, buying some time to stabilise what we're working on now.
>>>>
>>>>
>>>>         
>>> I think we should do that. I'm also tempted to suggest we consider limiting
>>> our development until we've fixed these tests up. Or alternatively control
>>> the rate of patch merging so we can pace it and make sure the tests get
>>> focus.
>>>
>>> That's a bit sledgehammer but...
>>>
>>>
>>>       
>> Ok, sounds like a plan, how do you think we should best approach the task?
>>
>> Create a branch in skunk, just for qa and run tests against released jars?
>>
>> Regards,
>>
>> Peter.
>>
>>
>>     
>
>
>   


Mime
View raw message