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 > > _______________________________________________ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
