Community |
Community.IRCmeeting20140924 HistoryHide minor edits - Show changes to markup January 23, 2015, at 04:00 PM
by
- Changed line 27 from:
17:59 < razvanc> | Hi all! to:
17:59 < razvanc>| Hi all! Changed line 29 from:
18:00 < razvanc> | I'm great, looking forward to start the second public meeting to:
18:00 < razvanc>| I'm great, looking forward to start the second public meeting Changed line 31 from:
18:01 < razvanc> | I'll be the show maker today, since Bogdan is currently unavailable to:
18:01 < razvanc>| I'll be the show maker today, since Bogdan is currently unavailable Changed lines 33-37 from:
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 to:
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 Changed lines 39-40 from:
18:05 < razvanc> | but rather only use the current code for testing and experimental stuff 18:05 < razvanc> | what do you think about this? to:
18:05 < razvanc>| but rather only use the current code for testing and experimental stuff 18:05 < razvanc>| what do you think about this? Changed lines 43-45 from:
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 to:
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 Changed lines 47-49 from:
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 to:
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 Changed lines 51-52 from:
18:09 < razvanc> | yes, exactly 18:09 < razvanc> | well, that's the first step to:
18:09 < razvanc>| yes, exactly 18:09 < razvanc>| well, that's the first step Changed lines 56-57 from:
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 to:
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 Changed lines 61-62 from:
18:12 < razvanc> | yes, correct 18:13 < razvanc> | so, if there are no other objections, I'll consider everybody is happy with this :) to:
18:12 < razvanc>| yes, correct 18:13 < razvanc>| so, if there are no other objections, I'll consider everybody is happy with this :) Changed lines 68-70 from:
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 to:
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 Changed line 72 from:
18:21 < razvanc> | do you happen to know the reason why they removed this? to:
18:21 < razvanc>| do you happen to know the reason why they removed this? Changed line 75 from:
18:24 < razvanc> | we thought it is worth proposing this scheme because it is easier to manage the opensips version status to:
18:24 < razvanc>| we thought it is worth proposing this scheme because it is easier to manage the opensips version status Changed lines 79-81 from:
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 to:
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 Changed lines 85-88 from:
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 to:
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 Changed lines 90-100 from:
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? to:
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? Changed line 102 from:
18:40 < razvanc> | yes, sure to:
18:40 < razvanc>| yes, sure Changed line 104 from:
18:42 < razvanc> | for major releases? to:
18:42 < razvanc>| for major releases? Changed line 106 from:
18:42 < razvanc> | roughly to:
18:42 < razvanc>| roughly Changed lines 108-109 from:
18:43 < razvanc> | yes, minor releases don't get new features 18:43 < razvanc> | only bug fixes to:
18:43 < razvanc>| yes, minor releases don't get new features 18:43 < razvanc>| only bug fixes Changed lines 111-112 from:
18:43 < razvanc> | and minor releases can be done anytime 18:43 < razvanc> | yes, only major releases are scheduled every year to:
18:43 < razvanc>| and minor releases can be done anytime 18:43 < razvanc>| yes, only major releases are scheduled every year Changed line 119 from:
18:47 < razvanc> | capncrunch4me: that's something we should have in mind for the next summit sessions to:
18:47 < razvanc>| capncrunch4me: that's something we should have in mind for the next summit sessions Changed line 121 from:
18:49 < razvanc> | sure let's move this on the list too to:
18:49 < razvanc>| sure let's move this on the list too Changed line 123 from:
18:51 < razvanc> | usually people prefer stability over innovation to:
18:51 < razvanc>| usually people prefer stability over innovation Changed line 125 from:
18:51 < razvanc> | having more time for testing, means better stability for production platform to:
18:51 < razvanc>| having more time for testing, means better stability for production platform Changed line 127 from:
18:51 < razvanc> | however, as liviuc said, one can always backport an interesting feaure it desperately needs to:
18:51 < razvanc>| however, as liviuc said, one can always backport an interesting feaure it desperately needs Changed line 130 from:
18:53 < razvanc> | :) I agree to:
18:53 < razvanc>| :) I agree Changed line 132 from:
18:54 < razvanc> | that's true :D to:
18:54 < razvanc>| that's true :D Changed line 135 from:
18:54 < razvanc> | and it is something we encourage to:
18:54 < razvanc>| and it is something we encourage Changed line 138 from:
18:55 < razvanc> | yes to:
18:55 < razvanc>| yes Changed line 144 from:
18:59 < razvanc> | not really, it is not such a hard work to do a release every once in a while to:
18:59 < razvanc>| not really, it is not such a hard work to do a release every once in a while Changed lines 146-148 from:
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 to:
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 Changed lines 150-151 from:
19:02 < razvanc> | to discuss and gather your opinions :) 19:02 < razvanc> | so let's see what others have to say about this to:
19:02 < razvanc>| to discuss and gather your opinions :) 19:02 < razvanc>| so let's see what others have to say about this Changed line 153 from:
19:03 < razvanc> | will open a thread about this too on the mailing list to:
19:03 < razvanc>| will open a thread about this too on the mailing list Changed line 155 from:
19:03 < razvanc> | anything else to add? any other thoughts, remarks or suggestions related to the topics we've discussed today? to:
19:03 < razvanc>| anything else to add? any other thoughts, remarks or suggestions related to the topics we've discussed today? Changed line 158 from:
19:05 < razvanc> | I would too, but it seems everybody is busy to:
19:05 < razvanc>| I would too, but it seems everybody is busy Changed line 160 from:
19:05 < razvanc> | discussing this on the mailing list would offer them more time to think to:
19:05 < razvanc>| discussing this on the mailing list would offer them more time to think Changed lines 165-167 from:
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 to:
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 Changed lines 170-172 from:
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 to:
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 Changed lines 174-175 from:
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 to:
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 Changed line 177 from:
19:12 < razvanc> | I will post the conclusions of this meeting on the website tomorrow and open the two threads we discussed to:
19:12 < razvanc>| I will post the conclusions of this meeting on the website tomorrow and open the two threads we discussed September 25, 2014, at 11:12 AM
by
- Changed lines 18-20 from:
TO ADD to:
Changed lines 26-179 from:
TO ADD to:
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 September 17, 2014, at 03:50 PM
by
- Changed line 8 from:
to:
September 17, 2014, at 03:39 PM
by
- Changed lines 6-12 from:
TODO to:
OpenSIPS 2.0
August 29, 2014, at 03:29 PM
by
- Added line 12:
TO ADD August 29, 2014, at 03:29 PM
by
- Added lines 1-18:
|