Login | Register

Community

Community -> PublicMeetings -> 24th of September 2014

Topics

OpenSIPS 2.0

  • Old OpenSIPS 2.0 will become OpenSIPS Experimental. It will never be released, but only used as a playground for testing new concepts. All the validated concepts will be imported to the main OpenSIPS project.
  • Release policy
    • the odd versions will be reserved for unstable/beta versions (i.e. the current OpenSIPS 1.12[trunk] will become OpenSIPS 2.1[trunk/devel])
    • the stable released versions will get only even numbers - next stable release will be OpenSIPS 2.2
  • Release timing: the release cycle should be increased from 6 to 12 months. This provides the community more time for testing and developing new features between releases and reduces the frequency of upgrades.

Conclusions

  • Renaming the old OpenSIPS 2.0 to OpenSIPS Experimental is a good idea because it will give us more flexibility when naming future releases of the main OpenSIPS project
  • This release naming scheme will provide more information about the status of the version in use, whether it is a beta/unstable or stable one.
  • Although this increases the time for developing and testing new features in OpenSIPS, it also increases the time new functions are released. Brett suggested that we should keep the current release scheme. We will continue this discussion over the mailing list: TODO?.

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


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