====== Chat log IRC Devel Meeting - 2013-09-12 ====== ===== outstanding issues at this time, if any ===== [16:00 - [16:06] are missing from my chat client, sorry\\ [16:06] the last one was sent to sr-dev, iirc\\ [16:06] the minutes\\ [16:07] oej: yes, it seems for the last one are only on sr-dev (at least not on wiki)\\ [16:07] Vicente was sending them\\ [16:08] ok … no outstanding issues for now\\ [16:08] next topic\\ ===== roadmap to next major release ===== [16:08] let's do planning for next minor release\\ [16:08] and do major release at the end\\ [16:09] after we see the near future plans for development.\\ [16:09] hello\\ [16:09] last minor release was in August 15\\ [16:09] perhaps we can do one by end of September or so (before Astricon)\\ [16:10] sounds good\\ [16:10] I haven't looked at patches since 4.0.3, but I remember I did a few of them\\ [16:11] one crash is fixed on ua_redirect\\ [16:11] linuxmaniac: ok, thanks for it\\ [16:11] miconda: my pleasure :-)\\ [16:12] oh not shure if patch was sent but there is small bug in presence module\\ [16:12] at least it's still at 4.0.3\\ [16:12] ok then -- 4.0.4 by end of September\\ [16:12] \o/\\ [16:12] ZogG_laptop: send it over sr-dev\\ [16:12] or put it on the tracker\\ [16:12] if already fixed, will be marked as done\\ [16:13] what people prefer to do now -- the techical (devel) topics or the admin ones?\\ [16:14] tech?\\ [16:14] ok\\ [16:14] first come first served\\ [16:14] technical topics\\ ===== xcap-diff - purpose and testing ===== [16:14] one I wanted to get some input is about xcap-diff\\ [16:15] as I said during last irc meeting I will try to do it before next major release\\ [16:15] miconda: not sure if it would be right one. the problem that docs states that reginfo_handle_notify() doesn't get any parameters while in code it does want one\\ [16:15] so just changing 1 to zero fixed the error from script\\ [16:15] ZogG_laptop: maybe is not the right fix, if it expects some parameter\\ [16:16] but report it and we look at\\ [16:16] ok thanks\\ [16:16] i'll do\\ [16:16] carstenbock is the developer, iirc\\ [16:16] That's right, i implemented it.\\ [16:16] and I saw some reports on tracker this morning\\ [16:16] Haven't looked at the recent bug-reports, though.\\ [16:17] that ruid is not set for records\\ [16:17] Putting the bug on the tracker is the best way.\\ [16:17] some are already there (regarding reginfo)\\ [16:17] ok, back to my xcap-diff, maybe pdunkley can comment\\ [16:18] Definitely in favour of getting xcap-diff support.\\ [16:18] from quick check of the specs, looks like the body for notifies has to be pretty much the xml chunk that was uploaded with put\\ [16:18] is it right?\\ [16:19] Sort-of.\\ [16:19] I started to add, pua and presence should be able to handle them\\ [16:19] the missing part is the publish from xcap-server\\ [16:19] Problem is that NOTIFYs must be throttled, for example no-more than one per five second period per dialog.\\ [16:19] So what do you do if there are two changes to the document in that period?\\ [16:19] pdunkley: everything is sort-of in SIMPLE :-)\\ [16:19] throttling is required by specs?\\ [16:20] And of course, you can only have one NOTIFY outstanding at a time, so you can't send the second until you have a final response to the first.\\ [16:20] can we just say at some point, hey, just take the full docs\\ [16:20] The base SUBSCRIBE/NOTIFY spec. mandates throttling and recommends 5s for presence.\\ [16:21] It's up to each specification that defines an event-package to say what the throttle rate should be, but the spec. does have to say it.\\ [16:21] If the xcap-diff spec. doesn't I'd think it needs to be the SUBSCRIBE/NOTIFY default of 5s.\\ [16:21] I think you can basically say "the doc has changed and it is too complicated for a patch - so just get it again".\\ [16:22] That'd be a good starting point for the first version.\\ [16:22] The presence module already has NOTIFY throttling in it, so if you do say "get the whole doc" all of the time it should just work (I think).\\ [16:22] ok, so we can go with kind of workaround, if we have many changes within the throttling interval, then just mark it for complete refresh?!?\\ [16:23] keeping the list of diffs can get complex otherwise\\ [16:24] I agree.\\ [16:24] ok, for now I am fine with this topuc\\ [16:24] This is the server side of xcap-diff?\\ [16:24] yes\\ [16:24] So it allows presence servers and UAs to SUBSCRIBE to the XCAP server?\\ [16:25] Is there any need or desire to do the client side of xcap-diff at some point?\\ [16:25] yes, do you want a client?\\ [16:25] maybe for those implementing sip clients...\\ [16:25] This would mean the presence module and rls modules could subscribe to the XCAP server (including a non-Kamailio XCAP server) instead of the proprietary \\ internal links.\\ [16:26] There is already the XCAP client module in Kamailio that can be used when presence/rls and xcap-server don't share a DB.\\ [16:26] for now my focus is on server\\ [16:26] OK, just checking.\\ [16:27] Does anyone know of a good (and free) client that supports xcap-diff?\\ [16:27] xcap client is just xcap -- no sip/presence in it, which will be required here\\ [16:27] so I assume it would have to be a pua_XXX module\\ [16:27] The only one I know of is Blink. But not sure how good the other bits of Blink presence are...\\ [16:28] pdunkley: probably not, but I though you will add it to your communicator :-)\\ [16:28] Lol\\ [16:28] i have tested sipclients presence and found bugs in it that have not been fixed\\ [16:28] We are quite happily using XMPP in a CUSAX like way at the moment.\\ [16:28] i am not aware of a good ones, free or not\\ [16:28] pdunkley: ok\\ [16:29] May do SIP presence and XCAP in the future, if there is demand for it.\\ [16:29] ok, then let's mark this topic done\\ [16:29] next one: dialog vs dialog_ng\\ ===== dialog vs. dialog_ng ===== [16:29] I don't see Jason here for getting more details about dialog ng\\ [16:30] anyone else here using it? (carstenbock)\\ [16:30] I am a heavy user.\\ [16:31] so what are the differences?\\ [16:31] There are some differences between dialog and dialog_ng. A big part is actually, that you can tear down calls even during setup-phase.\\ [16:31] What's the plan\\ [16:31] tear?\\ [16:31] terminated\\ [16:31] oh\\ [16:31] hang up\\ [16:32] e.g. if the network fails during call-setup (detected via Diameter-Rx), you can terminate a call if it is not connected yet.\\ [16:33] but there were some parts missing from the old dialog, or all features of the old dialog are in dialog_ng?\\ [16:33] That's about the main difference. I think another difference is, that the API has a direct function for terminating calls.\\ [16:33] What is missing (as with most IMS-modules actually), is the database-backend.\\ [16:34] All information is only in memory at the moment.\\ [16:34] are all the rpc commands there?\\ [16:35] carstenbock: that's fine, kamailio just keeps running\\ [16:35] :-)\\ [16:35] Exactly that's the case... ;-)\\ [16:35] Who needs to depend on databases then?\\ [16:35] A new definition of "no-sql"\\ [16:35] Jason also mentioned, that they implemented a lot of the stuff that's was in a wiki page about improvements in the dialog module.\\ [16:36] I don't know, what they all implemented from this page: http://www.kamailio.org/dokuwiki/doku.php/modules-new-design:dialog-module-design\\ [16:37] ok, db backend is important -- I will try to catch up with Jason on mailing lists\\ [16:38] I had in mind to do some cleanup on the matching modes of the old dialog\\ [16:38] probably I will still do it\\ [16:39] i see there is option to get dialog by cutom added key (from module doc get_dlg_var (dlg, key) )\\ [16:39] Regarding matching modes: dialog_ng does only matching on SIP-Elements, nothing else.\\ [16:39] I don't think we have that in dialog_ng (yet).\\ [16:40] carstenbock: yes, that was my plan as well, plus few optimizations for faster matching\\ [16:40] I'll see if I have enough time\\ [16:40] anything else on the technical side?\\ [16:41] I assume the code restructuring will be postponed, doesn;t look like enough time for it\\ [16:41] I can confirm, dialog_ng works excellent (for me in my setups)\\ [16:41] carstenbock: all our homeworks worked at home :-)\\ [16:41] I don't disagree with you, actually\\ [16:42] in the old dialog module we still see a stuck dialog if a 486 and 200 is received at more or less exactly the same time\\ [16:42] just that many features might be missing\\ [16:42] so regards that function, does it as well support dialog properties?\\ [16:42] kolbu: with latest 4.0 branch?\\ [16:42] running 4.0.3 ++\\ [16:42] that is, a few days after 4.0.3\\ [16:43] kolbu: what state it hangs on?\\ [16:43] 4\\ [16:43] e.g. from_tag/caller_contact/etc or it does support only custom added ones from set_dlg_var ?\\ [16:43] are read dialogs from db in dialog-ng ?\\ [16:43] which is good, because then we can close it with the dlg_end_dlg fifo\\ [16:43] are read dialogs from db in dialog-ng _planned_?\\ [16:43] iZverg: afaik no db implantation was made for dialog_ng\\ [16:44] Not yet. That will follow.\\ [16:44] kolbu: maybe you can open a tracker item and add some details there\\ [16:44] DB-Support is definitely planned, but not scheduled yet...\\ [16:45] i think in dialog need ability to read dialogs from db\\ ===== memcached module ===== [16:46] and memcached multiple servers. as i see no developer for memcached now?\\ [16:46] miconda: ok, will do\\ [16:46] * dr wants the memcached module that compiles with libmemcached in kamailio 4.0.4 :) \\ [16:46] iZverg: memcached module was refactored rather recently\\ [16:46] worth mentioning that the dialog module in 4.0 is sooo much more reliable than in 3.3\\ [16:46] so there are developers for it\\ [16:47] kolbu: ok\\ [16:47] dr: I think devel version compiles with that lib\\ [16:47] perhaps henningw or cchance can confirm that\\ [16:47] yes miconda, we've been testing it , it works\\ [16:47] ok\\ [16:47] yes, it compiled but only one server supported\\ [16:48] the library has support for more server, i think\\ [16:49] should be not to hard to extend, patches are as always welcome :)\\ [16:49] the devel version uses the new library\\ [16:49] s/new/good library\\ [16:49] ok\\ [16:49] anything else on technical aspects?\\ [16:50] other modules to add/fix/remove?\\ ===== presence_dialoginfo module ===== [16:50] the presence one\\ [16:50] ZogG_laptop: what you mentioned already, right?\\ [16:50] nope\\ [16:51] improvemnet\\ [16:51] there is force_single mode or something like that\\ [16:51] which would send only 1 state in xml\\ [16:51] early/confirmed/etc\\ [16:51] it would pick up mostly randomly\\ [16:52] you refer to presence_dialoginfo module?\\ [16:52] I've got a bunch of updates to the sca module to pull into 4.x and master.\\ [16:52] leme check\\ [16:53] miconda: yes\\ [16:53] admorten: ok, you should do it soon so they get tested\\ [16:53] ZogG_laptop: ok\\ [16:53] Will do.\\ [16:53] miconda: the priority should be early->confirmed->terminated\\ [16:53] ZogG_laptop: again, perhaps opening an item on tracker will help not forgetting and checking it\\ [16:54] having working dialog profiles would be nice\\ [16:54] miconda: ok. i even may try to get patch for this one\\ [16:54] ZogG_laptop: that is even better, thanks\\ [16:54] miconda: it would be better though if it would be checked before applied\\ [16:54] dr: they seem fine, you have troubles with?\\ [16:55] Re: our own sca module deployment. We now have 8345 SCA subscribers, and I've been hearing from a number of other places that they're rolling it out.\\ [16:55] ZogG_laptop: sure, they will be reviewed\\ [16:55] admorten: nice, thanks for sharing the numbers\\ [16:55] admorten: is a single sca server?\\ [16:56] Yes, at the moment.\\ [16:56] # set_dlg_profile("caller", "count");\\ [16:56] ## get_profile_size("caller","count","$avp(callcount)");\\ [16:56] ## xlog("L_INFO","number of simultaneous dialogs: $avp(callcount)\n");\\ [16:56] not bad then, for handling lots of xml docs\\ [16:56] i want it to decrement automatically\\ [16:56] Right. We have a replicated environment for failover.\\ [16:56] it doesn't , it always increments that counter\\ [16:56] miconda: SCA doesn't use XML. :)\\ [16:56] admorten: ok, that;s different\\ [16:57] but you said at some point that does dialog-info as well\\ [16:57] or I misunderstood?\\ [16:57] or you don't use that part...\\ [16:57] That'd be BLA, which we struggled with.\\ [16:57] Need to know how to enable kamailio to send file over a NATED network\\ [16:57] any hel\\ [16:57] help???/\\ [16:57] XML bodies would grow massive, then packet fragmentation would overwhelm the handsets.\\ [16:58] Inconsistent state across the groups.\\ [16:58] dr: it will be decremented when the dialog is ended/destroyed\\ [16:58] kethzer: you have to wait a bit for support questions, we are doing development and admin meeting\\ [16:58] miconda, that's what I thought too, but this does not happen with my script\\ [16:59] i had to put the counter in memcache , and increment / decrement manually\\ [16:59] I do use it in many places, no problem so far...\\ [16:59] what version are you using?\\ [16:59] 4.0.2\\ [17:00] you should shift to latest in 4.0 branch, there were some fixes for negative replies\\ [17:00] or do dialog related things just before t_relay()\\ [17:01] dr:are you trying to get total dialogs per subscriber?\\ [17:01] and http_query() from the utils module , it might need some heavy improvements, it returns only the first line from the buffer\\ [17:01] It is documented to only do that :-)\\ [17:01] ZogG_laptop, no , total number of dialogs\\ ===== http modules ===== [17:02] But yes, we need improvements in http_client\\ [17:02] Sorry, I would say we need a http_client module that consolidates all http clients\\ [17:02] We have several different ones\\ [17:02] dr: speaking of that, I think carstenbock did some work on http client lately\\ [17:03] but iirc, he pushed on a personal branch\\ [17:03] There's one in utils, one in jsonrpc and one in xcap client and possibly sip identy\\ [17:03] From the top of my head. Some use libcurl.\\ [17:03] oej: right, maybe we should pull out http client part from all modules and have one that will be reused\\ [17:04] I think that would be a good thing moving forward.\\ [17:04] jsonrpc client uses netstrings, iirc\\ [17:04] is not over http\\ [17:04] Then we could get IPv6 in every one and solve happy eyeballs once.\\ [17:04] miconda, thx . one more thing: i don't think the dialog module works very good with event_route[tm:local-request] either . $DLG_TIMEOUT is not getting set\\ [17:05] dr: has to be checked, not using it like that so I cannot comment now -- open an issue on tracker to have it in mind\\ [17:05] carstenbock: any comments on your recent work on http cleint?\\ [17:05] $DLG_lifetime, sorry\\ [17:06] ok, let's move forward (probably carstenbock has left a bit)\\ [17:06] anything else on tech stuff?\\ [17:06] how about mediaproxy-ng module?\\ [17:07] Question about core support for maximum branches. We're currently limited by a 32-bit mask to 30 branches. I have some early work moving to 64-bit mask for branch tracking. Anyone else interested?\\ ===== rtpproxy_ng ===== [17:07] jh: rtpproxy_ng?\\ [17:07] admorten: yes, could be interesting\\ [17:07] miconda: https://github.com/sipwise/mediaproxy-ng\\ [17:08] push the patches somewhere for some review\\ [17:08] yes, ment rtpproxy-ng (naming is confusing)\\ [17:08] miconda: OK\\ [17:08] jh: yes, I know, quite confusing in both sides, even the external application\\ [17:08] I'll put them up on sip-router tracker and post to sr-dev when ready.\\ [17:08] there was some bugs found. will those be fixed before next release?\\ [17:09] probably yes. I don't see Richard here\\ [17:09] but I guess sipwise is highly interested to get all bugs closed\\ [17:09] miconda: :yes:\\ [17:09] linuxmaniac may be able to comment more\\ [17:09] I know some were fixed already\\ [17:10] hughw: send some patches as well, e\\ [17:10] were they done?\\ [17:10] miconda: afaik yes\\ ===== http modules ===== [17:10] (sorry for the delay: i just added support for POST-requests to the http_query() function. Needs a little bit testing, but should be okay)\\ [17:10] rephrasing: hughw sent some patches to rtpproxy-ng\\ [17:10] I think they are been merged\\ [17:10] linuxmaniac: ok\\ [17:11] carstenbock: ok, maybe you should merge on master, to be easy to test for not-git gurus :D\\ [17:11] carstenbock: Using curl?\\ [17:12] carstenbock: in short, it was a discussion to make a single http client module, as there are few other modules implementing one internally\\ [17:12] miconda: Will do that.\\ [17:12] oej: Yes.\\ [17:12] carstenbock: Which module is that?\\ [17:13] oej: utils\\ [17:13] ZogG_laptop: for clarification - the external application is named mediaproxy-ng, but the corresponding module in kamailio is named rtprpoxy-ng\\ [17:14] miconda: yeah, thanks, got it from conversation above and some google\\ [17:14] :)\\ [17:14] Ok, so we should propably build an improved http get in utils, as well as something similar to json that suspends transaction and returns in another route\\ [17:15] i think http get/post would be enuf and what would be needed are modules to parse responses (json/xml/whateverelse)\\ [17:17] ok, done with tech stuff?\\ ===== OpenSSL licence exception ===== [17:17] openSSL exception licence\\ [17:17] license\\ [17:18] oej: no mail from you on the mail list :-P\\ [17:18] linuxmaniac: ok, that was the next in list\\ [17:18] I did brainstorm about it earlier this week\\ [17:18] :-)\\ [17:18] but I thought of it more admin stuff\\ [17:19] miconda: I can wait :)\\ [17:19] no, it is on now\\ [17:19] let's discuss it\\ [17:19] one way is to implement tls module with gnutls\\ [17:20] I think is "just" a matter add the exception clause\\ [17:20] carstenbock: How do I set content-type in the post data?\\ [17:20] the other one is getting devels to agree with the exception\\ [17:20] which most of them will do, but many are gone\\ [17:20] from the early stage of ser\\ [17:20] oh, about that. i got kaamilio 4.x crashed with tls when having reregister or two calls at the same time :(\\ [17:20] * ZogG_laptop was talking about tls\\ [17:21] also, lot of copyright is by fokus, which was sold to tekelec which was recently bought by oracle\\ [17:21] Oh yeah, let's consult Oracle lawyers\\ [17:21] haha\\ [17:21] so we may need to buy a beer to Larry\\ [17:21] So the problem here is that the tls module is not part of linux distros because of this, right?\\ [17:21] hehe\\ [17:21] ZogG_laptop: do you have a backtrace?\\ [17:21] OpenSSL is used by other modules (for access to the randomness and crypto routines).\\ [17:22] oej: I can't add tls on Debian because of that\\ [17:22] websocket, outbound, auth_ephemeral all link to it - BTW I am fine with the exception.\\ [17:22] Yes, there's a few modules that Debian won't accept\\ [17:22] linuxmaniac: the question is, all devs have to agree?\\ [17:22] so we can clear those three modules\\ [17:22] miconda: no here for sure. but i think i can emulate it anytime\\ [17:22] linuxmaniac: or only devs to the modules that link to openssl?\\ [17:23] because the core doesn't link to openssl, only few modules (tls among them)\\ [17:23] afaik i just read of some sip lib that switched for smaller lib for tls/ssl instead of openssl\\ [17:23] miconda: don't know, but I will say just the ones that use openssl\\ [17:23] ZogG_laptop: a backtrace would be good and eventually the log with debug=3\\ [17:23] What is the background of the TLS module, was code moved from the core to that?\\ [17:24] miconda: would try to get one to you thru maillist or tracker next week\\ [17:24] linuxmaniac: that would be easier\\ [17:24] Other modules are tls, osp, stun, auth_identity\\ [17:24] Andrei reimplemented tls module\\ [17:24] nothing from old openser core was used for it\\ [17:24] I guess pdunkley has nothing against to agree for websocket module\\ [17:25] Some of the stun stuff is mine, but most has been moved from Kamailio core. For my part I am happy with an exception for stun too (but the original author will need to confirm as well)\\ [17:25] miconda: I can try to ask on debian-legal and see what they say\\ [17:25] stun and auth_identity is from iptel.org guys\\ [17:25] linuxmaniac: please do it, so we know what we have to do\\ [17:25] pdunkley has three modules to disclaim, but that should be fine\\ [17:25] miconda: noted\\ [17:25] linuxmaniac: mention also that we package tls module separately\\ [17:26] linphone apprantly switched from openssl to https://polarssl.org/\\ [17:26] is not part of other package\\ [17:26] can we get agreement fron Andrei?\\ [17:26] miconda: I will send you the mail draft before send it to them\\ [17:27] Just checked, I can remove the OpenSSL dependency from stun with a trivial code change.\\ [17:27] but anyways we have to add the exception\\ [17:27] I am happy to disclaim my modules.\\ [17:27] oej: probably iptelorg\\ [17:27] That means websocket, stun, outbound, and auth_ephemeral are fine.\\ [17:27] but at least we know the target, I will get in touch if it all we need\\ [17:27] miconda: back to larry\\ [17:27] Leaves just tls, osp, and auth_identity\\ [17:28] for osp I can approach the company that developed it\\ [17:28] Transnexus\\ [17:28] although they were not very active, I guess they have nothing against\\ [17:28] oej: yes\\ [17:28] but not sure how many users that module has\\ [17:28] Auth_identity was a school, that should possibly be fine if we can track someone down\\ [17:28] afaik, only that company had a solution to work with it\\ [17:29] tls is a tough nut to crack and an important one\\ [17:29] yes, tls is the one that needs it most ...\\ [17:30] the other important one, websocket, is fine\\ [17:30] for stun, I guess we can reimplement it\\ [17:30] doesn't look that hard\\ [17:30] and is not big\\ [17:30] tls has lot of code, on the other hand\\ [17:30] Yep.\\ [17:31] ok i'm off. bye and goood luck to every one adn thanks for help.\\ [17:31] but first let's see what linuxmaniac gets from debian-legal and then I will see how to approach for tls + stun\\ [17:31] ZogG_laptop: thanks for joining!\\ [17:31] anything else about openssl exception?\\ [17:31] ok then\\ [17:32] and before i go i would paste again may be polarssl can be replacement for openssl as it mentioned on their site curl/openvpn and others are using it and afaik linphone switched ot it lately\\ [17:32] bye\\ [17:32] thanks, bye\\ ===== github clone ===== [17:32] next admin stuff: github\\ [17:32] Andreas Granig secured kamailio name on github\\ [17:33] pdunkley and few others expressed the willingness to maintain a clone of the repo there\\ [17:33] we have a mirror at sipwise\\ [17:33] Github would work best if that was the primary repo.\\ [17:34] so, do we get enough work force to maintain a clone\\ [17:34] Biggest advantage of Github is fork management etc.\\ [17:34] pdunkley: from Andreas I understood is a matter of some scripts to merge back and forth\\ [17:34] but in case of conflicts, someone has to care of ...\\ [17:34] Yes.\\ [17:35] I suppose that is true.\\ [17:35] pdunkley: but you can fork with no problem afaik\\ [17:35] But it needs to be more than a simple clone, because if someone forks on Github and makes a push request that is accepted, then the repo on Github is updated.\\ [17:35] the current repo is tied to many scripts and hooks around, so it will be quite some work not to keep it anyhow\\ [17:35] why did we leave sourceforge?\\ [17:36] besides the fact that github started to have issues (e.g., availability)\\ [17:36] pdunkley: the thing is that you have to do git am on our repo not github\\ [17:36] oej: when we merged the code, we had svn on sourceforge and ser was cvs on berlios\\ [17:36] we needed root privileges :-)\\ [17:36] to make things fit together\\ [17:37] sf.org had also some issues that time (they still have). One reason to go for a dedicated git was to have the flexibility to merge the repos\\ [17:37] Right.\\ [17:37] pdunkley: will not be a read only clone\\ [17:37] Will we end up in the same situation with github\\ [17:37] github can get updates directly there\\ [17:37] the scripts have to do sync both ways\\ [17:38] Andreas said is something they do as well for some of their repos\\ [17:38] afaik github is just a mirror for us\\ [17:38] I guess the big question is whether enough people think that Github provides advantages to the project.\\ [17:38] no changes from github onto our repo\\ [17:39] linuxmaniac: check sr-dev for Andreas' email on this topic\\ [17:39] My thinking is that the Github forking is a somewhat nicer model than having developers with lots of branches, and allows non-developers to work under source control without it automatically affecting the main project.\\ [17:40] pdunkley: agree that there could be good benefits. on the other hand, not keeping current one as the main one will be tough and lot of work\\ [17:41] so, at least have to keep/try both for a while just to see if github is good\\ [17:41] miconda: "Everytime you push something to the internal repo, the github repo gets automatically synced and overwritten"\\ [17:41] so no changes from github on our repo\\ [17:42] linuxmaniac: "people have the possibility to send pull requests and everything"\\ [17:43] miconda: yes\\ [17:43] but no merge is done\\ [17:43] so I assumed they are used ...\\ [17:43] miconda: you have to use git am on the "master" repo\\ [17:43] linuxmaniac, miconda: but does the internal repo get sync'd and overwritten everytime the github repo is changed?\\ [17:44]