[OpenSER-Devel] proposal: 1.4 not freezing tonight

[Bogdan-Andrei Iancu]

Hi Daniel,

 From my point of view we can delay indefinitely postpone any release, 
until all the functionalities that are subject to discussion or redesign 
are discussed and agreed upon. Also a reanalysis on the code to identify 
all the combinations between routes and functions should be taken in the 
consideration (there are several patching for enabling functions for the 
BRANCH_ROUTE). Why stopping only to the local_route and not processed to 
all similar issue - I really do not consider the local_route a special 
case and we should not encourage discrimination.


Now, seriously speaking, please excuse me for being sarcastic in 
presenting the problem, but it is exactly what you suggest. Any feature 
/ functionality is subject to evolutions, which means it starts from a 
simpler first version and evolves in time to a more complex one. We 
cannot to do the whole evolution in a single release - this takes time. 
And this was an important attribute of the project - often release to 
avoid big differences across version.

So, let's follow evolution in its natural way -  with small but 
continues steps and not in big jumps.

Regarding the vote - if you see a benefit in this, do a delay of the 
freeze. But this will create a highly dangerous precedent for the future!

Regards,
Bogdan
 

Daniel-Constantin Mierla wrote:
> Hello everybody,
>
> I want to ask for one more week of development before freezing 1.4. It 
> was already postponed 2 days, but last day changes makes me 
> uncomfortable about this major release.
>
> Today afternoon, less than 12 hours before release, a new feature was 
> announced, based on commits started last evening. It is about 
> introducing local_route.
> http://lists.openser.org/pipermail/devel/2008-June/014035.html
>
> Like other developers expressed the concern, the time didn't allow to 
> properly analyze and extend its usage across modules, in places that 
> will bring real benefits.
>
> The purpose for the route is to handle local generated requests via TM. 
> One example is the requests generated via MI interface (fifo, xmlrpc). 
> However, only a limited set of functionalities are possible now, due to 
> lack of time. For me is like a stub, it allows to add headers, do 
> accounting, logging, benchmarking and avp operations.
>
> I see no reason why not enable there very useful features, such as load 
> balancing, least cost routing, sip tracing and many other.
>
> As it is right now, the features brought in are suitable for a 
> send_route, where the routing was establish, nothing can be done in that 
> respect, but one wants to do just some polishing here and there, with 
> some new headers, logging and accounting. This route should be available 
> for all requests, not only for tm local generated ones.
>
> For this week, the plan will be:
> - developers that have functions they consider are useful to be 
> available in local_route, will take care to do it for their code
> - new features for local_route that are considered highly useful will be 
> added
> - I am going to analyze, propose for discussion and implement a send_route
>
> I consider that will make 1.4 a big step forward, rather than sticking 
> to this stage for one year (when probably will be 1.5).
>
> This is more or less a vote of the developers, but opinions are welcome 
> from anybody. If by mid of next week, will be a majority for delaying of 
> expressed votes, then will be unfreeze for one more week. Otherwise, the 
> freezing can be considered from tonight.
>
> My vote is to delay freezing with one more week.
>
> Cheers,
> Daniel
>
>