river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <...@dcrdev.demon.co.uk>
Subject Re: thoughts on River project organization...
Date Thu, 01 Feb 2007 15:38:57 GMT
Mark Brouwer wrote:
> Brian Murphy wrote:
>> On 1/31/07, Mark Brouwer <mark.brouwer@cheiron.org> wrote:
>>
>>> 3) merge ServiceUI and JTSK for the time being so we have one build
>>>     process,
>>
>>> 4) work towards an initial (internal) release that in all aspects
>>>     compatible with the current JTSK
>>
>>> 5) setup of test infrastructure to validate the outcome of 4
>>
>> For what it's worth, in order to achieve 4) it would seem that
>> doing 5) before 3) might be advisable.
> 
> You are right, my mistake, although I had in mind 5) is done in
> parallel with 3) and 4).
> 
>> existing and somewhat complete set of tests, along with a harness
>> for running those tests, I would think that it might be desirable
>> to establish a baseline by first getting that mechanism set up
>> and running before combining or modifying the initial codebase.
> 
> In case 5) can be done in a timely fashion I agree with you, I'm very
> worried that it won't be the case. I assume/hope a lot of eyes will be
> looking at the modifications that could compensate for the omission of a
> proper test framework for the initial period.
> 

-1

IMHO, we have a strong testing tradition that has lead to quality
releases.  The last thing we need is for an apparent simple first
release to suffer an attendant reduction in quality.

Unless of course, we want to start doing regular test builds which users
could thrash, we could fix and then produce a final release.  But I
suspect this kind of rapid iterating might not fit with being in the
Incubator or other people's mindsets.

> Therefore if 5) can't be arranged in a timely fashion I still think
> we should start with 3) and 4) as the current immobility is rather
> frustrating from my perspective, although if I'm the only one there is
> nothing to worry about.
> 
>> That way, when people do start changing the existing code,
>> they'll have a point of reference as well as a mechanism for
>> measuring the quality of their changes.
> 
> I agree (and not just to be political correct).


Mime
View raw message