- The GitHub concept of forking would make individual developers branches easier to manage. - The GitHub concept of forking and push-requests would make it easier for people who are not core developers to submit patches and for the core developers to review them and apply them. - People have been complaining about flyspray for a while and the GitHub tracker is nicely integrated into the repository making it easy to relate issues to code and patches. - The GitHub web-UI means that the code is easier to browse, inspect, view history (and relate changes to issues) than the "default" Git one that is in use at the moment. - There would be no need for anyone to spend time or money maintaining/patching/fixing the SIP Router Git repo and flyspray. - Someone else is handling backups and failure recovery. - The use of markdown means that documentation and code can be presented together in a nice way with GitHub. I am sure there are more too (which is why so many projects are on there now). Peter On 29 August 2013 08:49, Alex Balashov <abalashov(a)evaristesys.com> wrote: -- Peter Dunkley Technical Director Crocodile RCS Ltd

The advantages of concentration are lower costs and richer feature set. I am sure the time of the Kamailio developers is better spent on Kamailio than running a tracker, repo, and so on that still won't be as good as the concentrated one. If I was setting up an open-source project today I certainly wouldn't run the repo, tracker, etc myself - it just wouldn't make sense. Even if GitHub became evil in the future I could move. I think it makes sense for any project to review these kind of logistics from time to time as we are in a rapidly changing world, and given that there was some discussion about code re-structuring before the next major release a few months back, now would seem a logical time to give it some thought. I am quite happy with the status-quo if no-one wants to change but do think this merits some consideration to make sure we aren't missing out on something that could help us. Regards, Peter On 29 August 2013 09:41, Olle E. Johansson <oej(a)edvina.net> wrote: -- Peter Dunkley Technical Director Crocodile RCS Ltd

+1 for GitHub too On Fri, Aug 30, 2013 at 4:27 AM, Richard Brady <rnbrady(a)gmail.com> wrote: -- Carlos http://caruizdiaz.com +595981146623

At least some comments are not relevant as most of those commenting so far helper haven't helped in administration of the current system at all, so there was no real basis for comparison. From my point of view, the tracker on github is really basic and the weak point that I gave up on trying to figure out if worth migrate to it some time ago. I am not very happy with flyspray either, but works fair enough not to consider a migration when I have no time to do it myself. Anyhow, I did review other bugtracker systems, and all of them have inconveniences. Then, lately github started to get lot of problems, maybe because it became too loaded. Over the time, I learned/worked with two other 'cloud' hosting services, berlios and sourceforge. And I have to say that from time to time they did upgrades of the portals or underlying infrastructure, so one has to spend time in coversions or learning the new systems. The main issue is again: who is going to do the work and do that for long time. Like with restructuring of the code, there were voices for it, with proposals to write and send scripts for automatization, but that didn't happen so far. I don't think the restructuring of the code will happen for the next release, soon we will have to freeze the development. It is not that I am agaist github or other 'cloud' portal, at the end git is distrubuted system by design, so we can have it in many places. It is about who is doing the work and administration in long term. If we get a group of people committed to do it, we can have a middle way for a while. Have a clone on github that you syncronyze back and forth with current repository and see what people prefer to use over the time, then we can decide which is the main repo and eventually keep the other as backup. Obviously, controlling the system completely is a big benefit, but if proves that using a hosted one is better and reliable, then we can make a decision. But I would avoid asking and following just a blind vote from people that won't get into doing the actual work, for a thing that is not critical now. To summarize the way forward from my point of view: - there has to be a gourp of 3-5 people willing to use github and ready to maintain that as a clone for a while and syncronyze in both ways - try to advertise the benefits to convice more developers to use that portal for source code development - let at least several months to go on to see the evolution (some people might try and then return), then ask for a decision Cheers, Daniel On 8/30/13 2:28 PM, Alexandr S. Dubovikov wrote: -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Trainings - Berlin, Oct 21-24; Miami, Nov 11-13, 2013 - more details about Kamailio trainings at http://www.asipto.com -

Hello, I just want to add, that my comments about GitHub being easier to manage were entirely theoretical as I am one of those not involved in managing the servers. I merely added it as it is one of the many (perceived at least) advantages of a cloud deployment - and someone did ask what the advantages were. It might be that GitHub is entirely inappropriate for Kamailio, but I don't think it does any harm for someone to ask these kinds of questions from time-to-time as we are in an ever-changing landscape in terms of what is on offer out there. I'd like to think the decision not to use something that is currently considered to be the "best-of-breed" option by the open-source community is a deliberate one. Regards, Peter On 30 August 2013 15:58, Andreas Granig <agranig(a)sipwise.com> wrote: -- Peter Dunkley Technical Director Crocodile RCS Ltd

30 aug 2013 kl. 17:52 skrev Peter Dunkley <peter.dunkley(a)crocodilertc.net>et>: +1 to that. We should always have an open discussion and keep asking these questions. Why do we do what we do, and the way we do it? Have a great Kamailio weekend! Cheers, /O --- * Olle E Johansson - oej(a)edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden

Hello, I should be able to spend some time helping with something like this. Although, like everything else, I'd have to fit it in around other things. Peter On 30 August 2013 18:32, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote: -- Peter Dunkley Technical Director Crocodile RCS Ltd

Hello Peter, Admittedly, I am not intimately familiar with GitHub. But, of course, I have interacted with it in my use of numerous open-source projects hosted there (beyond just checking out Not to say that I know best, because I don't, but: On 08/29/2013 12:29 PM, Peter Dunkley wrote: How so? (I am not familiar with the GitHub concept of forking.) Admittedly, that would be attractive. Yes, but it would be practical or easy to migrate the existing Flyspray requests to that tracker? And does the tracker really command a substantial usability premium over Flyspray, or is this a matter of custom, habit and taste? I do believe that is a matter of custom, habit and taste. For instance, I am much more accustomed to Gitweb (the current UI) and appreciate it for its simplicity and lack of clutter related to GitHub's "collaborative" accoutrements and embellishments. I find it more difficult to navigate GitHub's layout, and I can't be the only one. The fact remains that the hosting is already provided in a professional manner by Kamailio's biggest corporate sponsor. Moreover, as always, running one's own repo and bug tracker opens up more possibilities for backend automation and integration with third-party tools. Of course, Git is Git, and I'm sure GitHub has some useful APIs, too, and it is likely that the project probably won't be needing such advanced integration in the near future. Still, it's always a trade-off when switching to a "cloud" service. Control is good. Somehow I suspect that is also the case currently. Yes, but Kamailio has an existing documentation presentation mechanism and a content engine for that purpose (Dokuwiki). Also, although Olle's point about concentration vs. decentralisation of the Internet is a bit more abstract, it resonates. In general, I think most of the technically-minded among us can agree that there are some deeply worrisome side effects from the lopsided concentration of e-mail services--and the physical control of e-mail servers--into the hands of Google, for instance. The substantial monopoly of online socialisation enjoyed by Facebook is equally disconcerting. This seems to have deleterious effects from the point of view of privacy and government surveillance, not to mention the ever-present problem of our eyeballs and attention spans being sold for marketing dollars. Now, obviously, privacy is not a concern for a public-facing open-source project. However, there is a common thread of philosophical concern here that we should probably heed. The arguments--related to workflow streamlining, economies of scale, and divestiture of non-core competencies--for "cloud services" are well-understood, and often make economic sense. However, they should be balanced against the reality that putting the project in GitHub puts the tools we use to develop it squarely in GitHub's control, and, in a very real sense, subjects us to the whims of GitHub, to the business objectives motives of GitHub, and to the very same of GitHub's prospective future investors or as-yet-unknown future owners. We become a very small fish in a very big sea that moves according to tides we don't control. That is, of course, the reality of virtually all economic interdependence and civilisational complexity, but I think we should carefully think about whether following the current "cloudy" fashions--together with the nice feature set on offer at GitHub, no doubt about it--is really in the best interests of the project. -- Alex -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/

On 08/30/2013 09:04 AM, Henning Westerholt wrote: To play Devil's Advocate against my own argument: none of that sounds like stuff that can't be from an automatic clone of the repository hosted on GitHub. Right? -- Alex -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/

Definitely we will keep our own web server, with downloads, wiki, etc. I assumed people are considering github only for git repository and eventually the tracker. On 8/30/13 3:06 PM, Alex Balashov wrote: Yes, but you will have to (re)write quite a bunch of scripts to do it and of course you are welcome to do it :-) Cheers, Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Trainings - Berlin, Oct 21-24; Miami, Nov 11-13, 2013 - more details about Kamailio trainings at http://www.asipto.com -