9 mar 2006 kl. 20.50 skrev Kevin P. Fleming:
Luigi Rizzo wrote:
so how about an interim solution where we carry on both the old say.c
and the new app_say.c, with a config-file switch to choose which
one, and after a while when we are confident that the new methods
is on par with the old one we get rid of say.c and things
keep working as before (or hopefully better)
I don't think there is a reason to do that extra work, unless we
are not
confident that we can have the new solution functional and bug free in
90 days or so. If we can, then I say move ahead as quickly as we can,
since we are allowed to have a partially broken/non-functional
development branch now :-)
Just a little bit of caution:
I worked together with some other people a whole summer implementing
the current syntaxes from a lot of untouched patches in the bug tracker.
There are quite a lot of stumbling blocks and "aha"s you will
discover as
you work with this, it's very hard to foresee all cases, different
requirements
and strange syntaxes.
Unless we have a large group of international testers, I am not
confident with ripping out the old code quickly, as it will break
backwards compatibility.
This is not easy, like all internationalisation issues.
Just my 10 eurocent.
/O
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
