Mark Brouwer wrote: > Brian Murphy wrote: >> On 1/31/07, Mark Brouwer <[EMAIL PROTECTED]> 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).
