On Sun, 2009-04-19 at 09:12 +0200, Alberto wrote: > Damian Krzeminski ha scritto: > > I know it's been a long wait: I sincerely hope that we switch back to a > > more reasonable "fixed release date" from current "fixed release content" > > model with sipXecs. It's not entirely up to me but I'll try to lobby for > > that. I'd like us to release sipXecs every 6 months (if not more often): so > > that people can try new features without using unstable builds. > > > I totally agree with Damian in this matter. The major objection I see in > this project, in respect of many other successful open source projects, > it's total uncertainty of release date. I'm sorry to say this, because I > appreciate the great work you do guys, but I've never seen (and I'm here > since 3.0) an estimated release date in the roadmap actually being > respected (maybe 3.4 that was a sort of surprise release). Right now 4.0 > roadmap release says end of March, but it was end of 2008 some time ago ...
Predicting when things will be done is very hard, but hitting a specific date set months in advance is even harder. Personally, I'd prefer never to set or publish a date at all, but instead to try to select a set of features that can be made stable together in a short 4-6 month cycle, and release them when they are ready. Anything that might take longer happens only on a branch, but maintaining a branch is extra work too so it's a balancing act. > I was following sipxbridge since it first appeared and > it was working fine with 3.10 even without a specific sipxconfig user > interface. It's a component that will need a lot of testing cause it > nature to be interoperable with a large array of ITSP. I think that a > deep testing of this component (with the wider range possibile of ITSP) > will happen only when it will be in a stable release. Again from a user > point of view sipxbridge could have been released in a maybe 3.12 long > time ago Actually, I don't think I'd agree with that - not because sipXbridge wasn't pretty good pretty early - it was, but it had almost no managment support until quite recently, and there have been many corner cases in interoperability between it and different phones and ITSPs and other services in just the last few weeks. This is in _no_way_ a criticism of sipXbridge or the developers who've contributed to it - it's purely a result of the very very difficult mission that component has. Nothing is ever perfect, but I'm much happier that we've been able to find and fix many of these issues _before_ we label that feature 'stable'. We've tried to stick to the notion that a feature really isn't ready for general release until it's got both good feature stability and good management support. Some users are of course more tolerant than others of deficiencies in one or the other of those, and we welcome and appreciate those hardy souls using and testing the development versions (that's why we publish them). I personally don't feel comfortable telling people that a release is 'stable' if it has a feature that has not had reasonable interoperability and robustness testing, or cannot be configured without fiddling with configurations by hand. Once such a feature is in the product, it can be a lot of work to pull it back out if it's slowing things down too much, so sometimes it's better to slip a release to get it really solid first. I think that our mission should be (is) to serve people who want a phone system that works, not a set of tools from which a hacker can build a system that mostly works. If you can live with 'mostly works', then many of the development versions fit that bill (of course, knowing which ones can be a bit tricky...), but if you just want to install it and use it and focus on other parts of your business, I'd like you to be able to trust that 'stable' designation to provide just that. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
