From openSIPS

Community: IRCmeeting20140924

Community -> PublicMeetings -> 24th of September 2014


OpenSIPS 2.0


IRC Logs

17:59 <     razvanc>| Hi all!
18:00 < capncrunch4>| hey razvan, how are you
18:00 <     razvanc>| I'm great, looking forward to start the second public meeting
18:00 < capncrunch4>| are you running the show today or is Bogdan?
18:01 <     razvanc>| I'll be the show maker today, since Bogdan is currently unavailable
18:01 <      saghul>| ohai!
18:01 <     razvanc>| :)
18:02 <     razvanc>| so today we don't have a technical discussion
18:02 <     razvanc>| what we want to discuss with you is the way the project will look from now on
18:03 <     razvanc>| as Bogdan already described, we are first planning to rename the old OpenSIPS 2.0 to OpenSIPS Experimental
18:04 <     razvanc>| since we are not planning to have a production ready OpenSIPS 2.0 any more
18:04 < capncrunch4>| ok
18:05 <     razvanc>| but rather only use the current code for testing and experimental stuff
18:05 <     razvanc>| what do you think about this?
18:07 < capncrunch4>| Im confused, is this just a naming convention thing? I mean, you are kind of already doing this
18:07 <     lirakis>| helo
18:07 <     razvanc>| hi lirakis 
18:07 <     razvanc>| yes, basically it is just a naming convention
18:07 <     razvanc>| but this will allow us to use the OpenSIPS 2.x naming for further OpenSIPS releases
18:07 < capncrunch4>| so are you planning on merging head and 2.0 to create experimental?
18:08 <     razvanc>| no, not really
18:08 <     razvanc>| the two projects will continue being separate 
18:08 <     razvanc>| but what we want to do is to import concepts from the current/old 2.0 to the main OpenSIPS project
18:09 < capncrunch4>| so it is purely naming convention. Makes sense to me.
18:09 <     razvanc>| yes, exactly
18:09 <     razvanc>| well, that's the first step
18:09 < capncrunch4>| i mean…it would be silly to be opensips 1.9999
18:09 <      liviuc>| not just naming! there will be a significant shift in design from OpenSIPS 1.x to 2.x
18:10 <      liviuc>| however, not as drastic as the current 2.0 is right now
18:10 <     razvanc>| yes, as liviuc says, the second step is to import several functionalities that were tested on the old 2.0 into the main branch
18:10 <     razvanc>| thus creating the new OpenSIPS 2.x
18:11 < capncrunch4>| makes sense…it a way to make more incremental growth in naming without creeping up against that 2.0 barrier
18:11 < capncrunch4>| and allows 2.0 to be more of an interim release
18:11 < capncrunch4>| (thumbsup)
18:12 <     razvanc>| yes, correct
18:13 <     razvanc>| so, if there are no other objections, I'll consider everybody is happy with this :)
18:13 < capncrunch4>| silence is golden
18:13 <      liviuc>| it is a lot easier for us as developers to manage the projects as well
18:13 <      liviuc>| it is quite hard to push both projects with the man-power we currently have
18:15 <      liviuc>| so, rather than letting great ideas not getting tested at all (current 2.0 design)
18:16 <      liviuc>| we feel the need to just import some of them into a fresh new OpenSIPS :)
18:17 <     razvanc>| ok, the next topic is related to the release policy
18:19 <     razvanc>| what we are trying to do is to follow the linux model: have the unstable/beta versions labeled with odd minors (2.1, 2.3, etc.) and the stable versions with even numbers (2.2, 2.4, etc.)
18:20 <     razvanc>| this  way the OpenSIPS status will be clear for everybody
18:20 < capncrunch4>| that may have been true up until 3.x linux….then that kinda goes out the door
18:21 <     razvanc>| do you happen to know the reason why they removed this?
18:22 < capncrunch4>| not really, there is alot of btrfs development going on in the kernel right now. Alot of that is driving versioning numbers
18:23 < capncrunch4>| but you are right in the odd/even numbering. It just isnt quite following the actual purpose of it right now, due to the aggressive filesystem development being done
18:24 <     razvanc>| we thought it is worth proposing this scheme because it is easier to manage the opensips version status
18:24 < capncrunch4>| im cool with odd/even versioning though on naming convention
18:25 < capncrunch4>| or numbering convention, rather
18:25 < capncrunch4>| so each even will be LTS?
18:27 <     razvanc>| not really
18:27 <     razvanc>| LTSs are released every two years iirc
18:28 <     razvanc>| so not all even versions will be LTS
18:30 < capncrunch4>| again, they are doing away with that in 3.x
18:30 < capncrunch4>| .10, .12, .14, .16 are all LTS in 3.x kernel
18:31 < capncrunch4>| are you planning on doing odd/even numbering and then doing ad-hoc LTS support
18:32 <     razvanc>| so we should have releases for odd numbers too, but only STS
18:32 <     razvanc>| and all even should be LTS
18:32 <     razvanc>| that would be interesting
18:32 <     razvanc>| it would be even more clear what kind of version you're using
18:33 < capncrunch4>| yeah
18:33 <     razvanc>| I think it's a subject that worths involving more people
18:34 <     razvanc>| and I will open a thread on the lists related to this
18:34 <     razvanc>| and we should continue the discussion over there
18:34 <     razvanc>| meanwhile, let's proceed to the next topic
18:34 <     razvanc>| the realising timing
18:35 <     razvanc>| currently we are releasing a version every 6 months
18:35 <     razvanc>| this means that for each version, we have around 4 months for developing and 2 months for testing
18:35 <     razvanc>| we find this time quite short
18:36 <     razvanc>| moreover having more releases means bigger migration efforts
18:36 <     razvanc>| that's why we would like to increase the release time from 6 to 12 months
18:37 <     razvanc>| any thoughts about that?
18:39 < capncrunch4>| so between releases, it will just be minor version numbers for bugfixes, etc.
18:40 <     razvanc>| yes, sure
18:41 < capncrunch4>| I feel like a year is a lifetime
18:42 <     razvanc>| for major releases?
18:42 < capncrunch4>| would it be 9 mos of dev and 3 mos of testing/migration?
18:42 <     razvanc>| roughly
18:42 < capncrunch4>| for major releases, yearly seems ok. Are you suggesting no features go into the minor releases?
18:43 <     razvanc>| yes, minor releases don't get new features
18:43 <     razvanc>| only bug fixes
18:43 < capncrunch4>| so new features get released every year
18:43 <     razvanc>| and minor releases can be done anytime
18:43 <     razvanc>| yes, only major releases are scheduled every year
18:44 < capncrunch4>| i suspect you will get pushback here from the community
18:44 <      liviuc>| the "yearly feature" party doesn't seem like a problem to me
18:45 < capncrunch4>| that suggests things like async will not be available until October 2015
18:45 < capncrunch4>| or other modules
18:45 <      liviuc>| if there is a really important feature that people could use, they could backport it and rebuild from code
18:46 < capncrunch4>| if you were to coordinate major releases with opensips summits, that would somewhat make sense
18:47 <     razvanc>| capncrunch4me: that's something we should have in mind for the next summit sessions
18:48 < capncrunch4>| I still think 1/2’ing the release cadence will get some pushback. I would suggest soliciting feedback from the list
18:49 <     razvanc>| sure let's move this on the list too
18:50 < capncrunch4>| my only concern would be allowing the project to be out innovated by similar projects due to release cadence
18:51 <     razvanc>| usually people prefer stability over innovation
18:51 < capncrunch4>| and while you are suggesting that you take a more incremental approach to the version numbers, you are actually going backwards on release cadence
18:51 <     razvanc>| having more time for testing, means better stability for production platform
18:51 < capncrunch4>| i agree and disagree
18:51 <     razvanc>| however, as liviuc said, one can always backport an interesting feaure it desperately needs
18:51 < capncrunch4>| testing in a vacuum is simply that, ie valgrind can only take you so far
18:53 < capncrunch4>| i say that having broken every stable opensips release and subrelease for the past 2 years
18:53 <     razvanc>| :) I agree
18:54 < capncrunch4>| i mean opensips is community supported, which means it is our job to break it ;)
18:54 <     razvanc>| that's true :D
18:54 < capncrunch4>| and we can break it in ways that arent available in a development environment
18:54 <      liviuc>| if only that would happen more often!
18:54 <     razvanc>| and it is something we encourage
18:55 < capncrunch4>| alright, so lets distill this down a bit
18:55 < capncrunch4>| this is all about setting expectations, right? The naming, the release cadence, etc.
18:55 <     razvanc>| yes
18:56 < capncrunch4>| I can tell you that from my perspective, Opensips is the best of breed as far as stability. It has taken that approach as a primary differentiator from something like Kamailion
18:56 < capncrunch4>| Kamailio
18:57 < capncrunch4>| you are suggesting that what you are current doing isnt working with 6 mos releases. I would argue otherwise.
18:58 < capncrunch4>| so, this feels like it is being motivated by something else. Are the maintainers burning out?
18:59 < capncrunch4>| it has also been my experience that more smaller iterations are much better than large iterations from a QC perspective
18:59 <     razvanc>| not really, it is not such a hard work to do a release every once in a while
18:59 < capncrunch4>| so why fix what isnt broken?
19:01 <     razvanc>| we believed that increasing the time for delopment and testing would increase the stability of the code
19:01 <     razvanc>| and we would also reduce the amount of work spent on migration
19:01 <     razvanc>| anyway, this is not something we settled, that's why we're having it as a topic
19:01 < capncrunch4>| sure, I just wanted to paint the picture for you
19:02 <     razvanc>| to discuss and gather your opinions :)
19:02 <     razvanc>| so let's see what others have to say about this
19:02 < capncrunch4>| sure! open dialog is great here
19:03 <     razvanc>| will open a thread about this too on the mailing list
19:03 < capncrunch4>| cool
19:03 <     razvanc>| anything else to add? any other thoughts, remarks or suggestions related to the topics we've discussed today?
19:03 < capncrunch4>| By the way, I am standing in as a proxy for brettnem on this discussion (hence why you probably dont recognize my handle).
19:05 < capncrunch4>| im cool, just wish there were more on here to weigh in. I suspect you will get alot more traction on the lists
19:05 <     razvanc>| I would too, but it seems everybody is busy
19:05 < capncrunch4>| yeah
19:05 <     razvanc>| discussing this on the mailing list would offer them more time to think
19:06 < capncrunch4>| yeap
19:06 < capncrunch4>| im super interested in the async stuff. Its kind of a driver for us, since the scale we operate at kind of requires it. Even to the point of bolting kamailio to the back of opensips just for database calls
19:06 < capncrunch4>| which……sucks.
19:07 < capncrunch4>| so hearing that it may be another year before it would be ready (due to yearly release cadences), it has me screaming NOOOO!!!
19:07 <     razvanc>| that's something bogdan is working for a while and we are planning to release it as soon as possible
19:08 <     razvanc>| we'll still have some interim releases with it, don't worry
19:08 <     razvanc>| but not stable ones
19:08 < capncrunch4>| yeah
19:08 < capncrunch4>| well if you need someone to test it, brettnem can certainly volunteer our 8k cps of production traffic at it
19:09 <     razvanc>| meaning that we won't offer LTS support for them, until they are properly tested - and this takes time
19:09 <     razvanc>| that would be great, thanks for offering!
19:10 <     razvanc>| so if nobody has anything else to add, we can close the meeting here
19:10 < capncrunch4>| im good
19:10 <     razvanc>| thank you very much for joining!
19:11 <     razvanc>| we really appreciate your input and will definitely consider it for our next discussion
19:11 <      liviuc>| thank you!
19:12 <     razvanc>| I will post the conclusions of this meeting on the website tomorrow and open the two threads we discussed
19:12 <      liviuc>| make sure to reply on the list to R&#259;zvan's threads for today's discussion

Retrieved from
Page last modified on January 23, 2015, at 04:00 PM