[OpenSER-Devel] trunk compilation warning

[Henning Westerholt]

On Thursday 18 October 2007, Dan Pascu wrote:
> > the current approach has the advantage that it allows someone to
> > specify which tables he want to use in the Makefile, other tables are
> > not generated.
>
> And what is the advantage in this? Why would I want to build only a few
> tables definitions instead of building them all?

I found this useful during the development of new tables, one could add them 
to the repository, but don't push them to all other people before there 
stable. The same argument applies to the standard or extra.. table 
definitions/ seperation in the openserctlrc file. 

In a first iteration of the schema generation system many tables were combined 
into one big "create" file, like create-core-tables.sql for all standard 
tables. This is still the way that the generation system works for SER. But 
we're decided in some discussion that we want to have more modularity, it 
should be possible to install only a few tables, if one want. 

Personally i would also go for the installation of all openser-* tables, but i 
don't see any need to challenge the descision from the discussion:

http://www.nabble.com/-Devel--database-setup-scripts-tf4455894.html#a12707220

> > Anyway, this don't qualify for me as bugfix or tools enchancement, so
> > its not possible to do this change at the moment in the trunk. So
> > please lets keep the current state for now.
>
> Here I disagree. To me this qualifies as an enhancement of the build and
> install process, which is something that should be done before the
> release. Enhancing the build/install process is not something that will
> affect how openser behaves and it can only be beneficial, considering
> that this is a 2 line fix in the Makefile and we have 2 months to test
> it.
>
> I'd like to hear other's opinions about this.
>
> > Yes, you're right. Its not possible at the moment to only install the
> > serweb or presence tables _without_ the core tables.
>
> Which is not the point. I'm sure this can be done, but the point is that
> is an unnecessary schism that has to be managed and dealt with.

All i can say that for some people this modularism is a good thing. The 
current system is available since May. You have had five month to communicate 
that you're not satisfied with this approach and redesign it after a consens 
had be reached.

The problem is not that this can't be done, or that i don't like it 
personally. The point is that we should focus our limited time and energy now 
on bug fixes and testing. The current approach is known now from developers 
and users, its documented in the wiki, coded into test scripts. So the costs 
of this change are higher than a "two line fix in the makefile".

Cheers,

Henning