[OpenSER-Devel] SF.net SVN: openser: [3972] trunk

[Daniel-Constantin Mierla]

On 04/04/08 13:50, Dan Pascu wrote:
> On Friday 04 April 2008, Henning Westerholt wrote:
>   
>> On Friday 04 April 2008, Dan Pascu wrote:
>>     
>>> [..]
>>> One of the issues I saw with almost every release of openser since
>>> 1.0.0 is the major disruptive changes that were in all of them. There
>>> was no release since then where I didn't have to completely rewrite
>>> my config script, alter my db schemas and update applications to use
>>> the new db schemas. The fact that after a release it can take up to a
>>> month to adjust the old environment to the new release and sort out
>>> all bugs, makes it a very innefficient approach when the release
>>> cycle is 6 months. This is why I would suggest we should generally
>>> use a less disruptive approach to things that minimized the migration
>>> path, especially if available and especially when (like in this case)
>>> would completely solve the problem rather than working it around.
>>>       
>> Dan,
>>
>> i understand your concerns, we all faces the same issues. But what are
>> the alternatives? Release only every 12 month or so means only even
>>     
>
> I do not think that less often releases would help a bit. On the contrary 
> they would probably make it worse. I would release often, but I would try 
> to have a more incremental approach, so that releases do not differ that 
> much.
>
>   
>> more update pain and bugs. Its also hard to do prober testing with such
>> a release. Do only minor changes? First of all, how do you qualifiy a
>> minor change? For me the siptrace stuff we're now discussing is such a
>> one, for you not. I think most people care mostly about the stuff that
>>     
>
> This siptrace stuff is just one of the many changes that will make 
> migrating from 1.3 to 1.4 harder than necessary, even more considering 
> that there is a possible good solution for this, but apparently opposed 
>   
I haven't seen anybody opposing such solution or contribution. I 
understand that will ease your life in the future, I see no reason why 
you don't start and develop it.
> because it takes more effort to do it than to just work around the 
> problem. But by working around the problem, we only make sure it'll 
> happen again in the future.
>   
You are not even sure your proposal is possible with openser currently. 
Again, feel free to re-factor the DB API layer to overcome this problem.

There are many workarounds done just to make the architecture be as much 
as possible db independent - see the functions added in postgres, mysql 
to satisfy the missing of auto_increment or functions from other db types.

There are functionalities that did not work with all db for quite some 
time because of db-specific constraints (in the past, parts of lcr, 
usrloc ...).

>   
>> there using intensivly, but this sets don't overlap necessarily that
>> much. Breakage and bugs are the price we pay for the progress we've
>> made.
>>     
>
> Bugs/changes can be minimized if we give the design phase a bit more 
> consideration, before jumping into coding something.
>   
I think there were discussions about db layer and other major changes on 
the devel and irc channels, announced to mailing lists. Not 
participating to, does not mean not existing. Everybody can get the 
initiative and lead topics. We like to make big waves just only when we 
get wet, otherwise we do not care about the whole.
>   
>> If you don't want to update every six months, feel free to use a stable
>> branch. 
>>     
>
> I use a stable branch, but that changes every 6 months and experience 
> shows that it always did in major ways.
>
>   
>> If you run out of the maintenance window of the project, you 
>> need to do some work by yourself. But its definitely manageable.
>>     
>
> This doesn't mean that it can't be improved and the amount of management 
> we need to do to move forward be minimized.
>
>   
>> If you think there is a better solution for some change, i welcome any
>> complains. But they will not change anything, the claims need to
>> supported with some code, research work, whatever. (This don't qualify
>> of course for a change that is plain wrong, or rejeced from the
>> majority of the developers.) Sure, it would be great if we had a mean
>> of proper quoting the colum names, but for now this is not available.
>> Daniel also aggreed that this name was a poor choice in the first time.
>>     
>
> Any name may be a bad choice as long as I have to consult 4 database docs 
> for keywords that may not overlap. Of course we can use names like 
> this_name_hopefully_is_not_a_keyword to avoid it :P
>
>   

-- 
http://www.asipto.com