On Thu, 2006-03-09 at 14:01 -0600, Stan Silvert wrote: > > > > > Another thing I was wondering. Why not make a clean break right > now? > > > That is, let each project have its own version of the common source > that > > > gets checked in today? Then they can be maintained independently. > > > > DRY principle! (don't repeat yourself) > > We should not have redundant code in impl and tomahawk, right? > > > > > > Manfred > > > > > > Thanks for the reply. Now I have a little more confidence that I > understand what is going on. > > I'm with you for everything except maybe the adherence to the DRY > principle. I'm not sure if it applies in this case. In a single > system, DRY is very important. However, we are talking about two very > different software systems - core and components. > > What happens when tomahawk needs to make changes to common that core > doesn't need? Ideally, this stuff would be moved out of common and into > tomahawk proper, but we know that over time this will not happen. > Instead, small, seemingly harmless changes will be made that do not > benefit both projects. > > A little core-specific stuff here, a little tomahawk-specific there, and > soon you have a single code base with divergent purposes.
There will be a single set of unit tests for shared; anyone making a change that breaks an existing unit test will need to think carefully. In addition, core has its own unit tests. If anyone does make a change to shared that breaks core, then next time anyone builds and tests core that should show up. Ok, the unit test coverage isn't that great now but hopefully that will improve. The same unit test stuff should apply to other users of shared, eg tobago/adf. A change to shared that breaks one of those will hopefully be noticed fairly quickly. The continuum "continuous integration" process is rebuilding and retesting everything on a regular (daily?) basis I believe... > > I think we should go for another principle: simplicity. Let's make a > clean break so that core and tomahawk can each fully go their own way. > It might mean some redundancy now, but I think it will be much simpler > for both projects in the future. This depends on the amount and complexity of the shared code. Cheers, Simon
