OpenSIPS 2.0
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ăzvan's threads for today's discussion