Hello,
There was some talk about restructuring the Kamailio code (for example, putting the core into an "src/" or "core/" directory and having an "include/" directory).
Would there be any mileage in considering a move to GitHub for the repository at the same time?
Regards,
Peter
Peter,
What do you see to be GitHub's virtues for this project?
Peter Dunkley peter.dunkley@crocodilertc.net wrote:
Hello,
There was some talk about restructuring the Kamailio code (for example, putting the core into an "src/" or "core/" directory and having an "include/" directory).
Would there be any mileage in considering a move to GitHub for the repository at the same time?
Regards,
Peter
-- Peter Dunkley Technical Director Crocodile RCS Ltd
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Sent from my mobile, and thus lacking in the refinement one might expect from a fully fledged keyboard.
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
- 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@evaristesys.com wrote:
Peter,
What do you see to be GitHub's virtues for this project?
Peter Dunkley peter.dunkley@crocodilertc.net wrote:
Hello,
There was some talk about restructuring the Kamailio code (for example, putting the core into an "src/" or "core/" directory and having an "include/" directory).
Would there be any mileage in considering a move to GitHub for the repository at the same time?
Regards,
Peter
-- Peter Dunkley Technical Director Crocodile RCS Ltd
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Sent from my mobile, and thus lacking in the refinement one might expect from a fully fledged keyboard.
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
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
29 aug 2013 kl. 18:29 skrev Peter Dunkley peter.dunkley@crocodilertc.net:
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).
Apart from this, there's a massive concentration of code and projects on a single site. Sourceforge now is rumoured to send malware with downloads, what can happen to github in the future? Is this concentration a Good Thing (TM) ?
The Internet is distributed. /O
Peter
On 29 August 2013 08:49, Alex Balashov abalashov@evaristesys.com wrote: Peter,
What do you see to be GitHub's virtues for this project?
Peter Dunkley peter.dunkley@crocodilertc.net wrote: Hello,
There was some talk about restructuring the Kamailio code (for example, putting the core into an "src/" or "core/" directory and having an "include/" directory).
Would there be any mileage in considering a move to GitHub for the repository at the same time?
Regards,
Peter
-- Peter Dunkley Technical Director Crocodile RCS Ltd
sr-dev mailing list sr-dev@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Sent from my mobile, and thus lacking in the refinement one might expect from a fully fledged keyboard.
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
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Peter Dunkley Technical Director Crocodile RCS Ltd _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden
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@edvina.net wrote:
29 aug 2013 kl. 18:29 skrev Peter Dunkley <peter.dunkley@crocodilertc.net
:
- 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).
Apart from this, there's a massive concentration of code and projects on a single site. Sourceforge now is rumoured to send malware with downloads, what can happen to github in the future? Is this concentration a Good Thing (TM) ?
The Internet is distributed. /O
Peter
On 29 August 2013 08:49, Alex Balashov abalashov@evaristesys.com wrote:
Peter,
What do you see to be GitHub's virtues for this project?
Peter Dunkley peter.dunkley@crocodilertc.net wrote:
Hello,
There was some talk about restructuring the Kamailio code (for example, putting the core into an "src/" or "core/" directory and having an "include/" directory).
Would there be any mileage in considering a move to GitHub for the repository at the same time?
Regards,
Peter
-- Peter Dunkley Technical Director Crocodile RCS Ltd
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Sent from my mobile, and thus lacking in the refinement one might expect from a fully fledged keyboard.
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
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Peter Dunkley Technical Director Crocodile RCS Ltd _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
- Olle E Johansson - oej@edvina.net
- Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
+1 for GitHub
On 29 Aug 2013, at 17:58, Peter Dunkley peter.dunkley@crocodilertc.net wrote:
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@edvina.net wrote:
29 aug 2013 kl. 18:29 skrev Peter Dunkley peter.dunkley@crocodilertc.net:
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).
Apart from this, there's a massive concentration of code and projects on a single site. Sourceforge now is rumoured to send malware with downloads, what can happen to github in the future? Is this concentration a Good Thing (TM) ?
The Internet is distributed. /O
Peter
On 29 August 2013 08:49, Alex Balashov abalashov@evaristesys.com wrote:
Peter,
What do you see to be GitHub's virtues for this project?
Peter Dunkley peter.dunkley@crocodilertc.net wrote:
Hello,
There was some talk about restructuring the Kamailio code (for example, putting the core into an "src/" or "core/" directory and having an "include/" directory).
Would there be any mileage in considering a move to GitHub for the repository at the same time?
Regards,
Peter
-- Peter Dunkley Technical Director Crocodile RCS Ltd
sr-dev mailing list sr-dev@lists.sip-router.org
-- Sent from my mobile, and thus lacking in the refinement one might expect from a fully fledged keyboard.
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
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Peter Dunkley Technical Director Crocodile RCS Ltd _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
- Olle E Johansson - oej@edvina.net
- Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Peter Dunkley Technical Director Crocodile RCS Ltd _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
+1 for GitHub too
On Fri, Aug 30, 2013 at 4:27 AM, Richard Brady rnbrady@gmail.com wrote:
+1 for GitHub
On 29 Aug 2013, at 17:58, Peter Dunkley peter.dunkley@crocodilertc.net wrote:
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@edvina.net wrote:
29 aug 2013 kl. 18:29 skrev Peter Dunkley <peter.dunkley@crocodilertc.net
:
- 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).
Apart from this, there's a massive concentration of code and projects on a single site. Sourceforge now is rumoured to send malware with downloads, what can happen to github in the future? Is this concentration a Good Thing (TM) ?
The Internet is distributed. /O
Peter
On 29 August 2013 08:49, Alex Balashov abalashov@evaristesys.com wrote:
Peter,
What do you see to be GitHub's virtues for this project?
Peter Dunkley peter.dunkley@crocodilertc.net wrote:
Hello,
There was some talk about restructuring the Kamailio code (for example, putting the core into an "src/" or "core/" directory and having an "include/" directory).
Would there be any mileage in considering a move to GitHub for the repository at the same time?
Regards,
Peter
-- Peter Dunkley Technical Director Crocodile RCS Ltd
sr-dev mailing list sr-dev@lists.sip-router.org
-- Sent from my mobile, and thus lacking in the refinement one might expect from a fully fledged keyboard.
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
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Peter Dunkley Technical Director Crocodile RCS Ltd _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
- Olle E Johansson - oej@edvina.net
- Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Peter Dunkley Technical Director Crocodile RCS Ltd
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
+1 . easy to manage....
8/30/2013 2:23 PM, Carlos Ruiz Díaz wrote:
+1 for GitHub too
On Fri, Aug 30, 2013 at 4:27 AM, Richard Brady <rnbrady@gmail.com mailto:rnbrady@gmail.com> wrote:
+1 for GitHub On 29 Aug 2013, at 17:58, Peter Dunkley <peter.dunkley@crocodilertc.net <mailto:peter.dunkley@crocodilertc.net>> wrote: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@edvina.net <mailto:oej@edvina.net>> wrote: 29 aug 2013 kl. 18:29 skrev Peter Dunkley <peter.dunkley@crocodilertc.net <mailto:peter.dunkley@crocodilertc.net>>:* 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).Apart from this, there's a massive concentration of code and projects on a single site. Sourceforge now is rumoured to send malware with downloads, what can happen to github in the future? Is this concentration a Good Thing (TM) ? The Internet is distributed. /OPeter On 29 August 2013 08:49, Alex Balashov <abalashov@evaristesys.com <mailto:abalashov@evaristesys.com>> wrote: Peter, What do you see to be GitHub's virtues for this project? Peter Dunkley <peter.dunkley@crocodilertc.net <mailto:peter.dunkley@crocodilertc.net>> wrote: Hello, There was some talk about restructuring the Kamailio code (for example, putting the core into an "src/" or "core/" directory and having an "include/" directory). Would there be any mileage in considering a move to GitHub for the repository at the same time? Regards, Peter -- Peter Dunkley Technical Director Crocodile RCS Ltd ------------------------------------------------------------------------ sr-dev mailing list sr-dev@lists.sip-router.org <mailto:sr-dev@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev -- Sent from my mobile, and thus lacking in the refinement one might expect from a fully fledged keyboard. Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 <tel:%2B1-678-954-0670> Web: http://www.evaristesys.com <http://www.evaristesys.com/>/, http://www.alexbalashov.com <http://www.alexbalashov.com/> _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org <mailto:sr-dev@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev -- Peter Dunkley Technical Director Crocodile RCS Ltd _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org <mailto:sr-dev@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev--- * Olle E Johansson - oej@edvina.net <mailto:oej@edvina.net> * Cell phone +46 70 593 68 51 <tel:%2B46%2070%20593%2068%2051>, Office +46 8 96 40 20 <tel:%2B46%208%2096%2040%2020>, Sweden _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org <mailto:sr-dev@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev -- Peter Dunkley Technical Director Crocodile RCS Ltd _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org <mailto:sr-dev@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev_______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org <mailto:sr-dev@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev-- Carlos http://caruizdiaz.com +595981146623
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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:
+1 . easy to manage....
8/30/2013 2:23 PM, Carlos Ruiz Díaz wrote:
+1 for GitHub too
On Fri, Aug 30, 2013 at 4:27 AM, Richard Brady <rnbrady@gmail.com mailto:rnbrady@gmail.com> wrote:
+1 for GitHub On 29 Aug 2013, at 17:58, Peter Dunkley <peter.dunkley@crocodilertc.net <mailto:peter.dunkley@crocodilertc.net>> wrote: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@edvina.net <mailto:oej@edvina.net>> wrote: 29 aug 2013 kl. 18:29 skrev Peter Dunkley <peter.dunkley@crocodilertc.net <mailto:peter.dunkley@crocodilertc.net>>:* 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).Apart from this, there's a massive concentration of code and projects on a single site. Sourceforge now is rumoured to send malware with downloads, what can happen to github in the future? Is this concentration a Good Thing (TM) ? The Internet is distributed. /OPeter On 29 August 2013 08:49, Alex Balashov <abalashov@evaristesys.com <mailto:abalashov@evaristesys.com>> wrote: Peter, What do you see to be GitHub's virtues for this project? Peter Dunkley <peter.dunkley@crocodilertc.net <mailto:peter.dunkley@crocodilertc.net>> wrote: Hello, There was some talk about restructuring the Kamailio code (for example, putting the core into an "src/" or "core/" directory and having an "include/" directory). Would there be any mileage in considering a move to GitHub for the repository at the same time? Regards, Peter -- Peter Dunkley Technical Director Crocodile RCS Ltd ------------------------------------------------------------------------ sr-dev mailing list sr-dev@lists.sip-router.org <mailto:sr-dev@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev -- Sent from my mobile, and thus lacking in the refinement one might expect from a fully fledged keyboard. Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 <tel:%2B1-678-954-0670> Web: http://www.evaristesys.com <http://www.evaristesys.com/>/, http://www.alexbalashov.com <http://www.alexbalashov.com/> _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org <mailto:sr-dev@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev -- Peter Dunkley Technical Director Crocodile RCS Ltd _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org <mailto:sr-dev@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev--- * Olle E Johansson - oej@edvina.net <mailto:oej@edvina.net> * Cell phone +46 70 593 68 51 <tel:%2B46%2070%20593%2068%2051>, Office +46 8 96 40 20 <tel:%2B46%208%2096%2040%2020>, Sweden _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org <mailto:sr-dev@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev -- Peter Dunkley Technical Director Crocodile RCS Ltd _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org <mailto:sr-dev@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev_______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org <mailto:sr-dev@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev-- Carlos http://caruizdiaz.com +595981146623
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hi,
On 08/30/2013 03:08 PM, Daniel-Constantin Mierla wrote:
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.
We're doing it the other way around at Sipwise: we've our own internal git server with the standard web interface etc., but it's configured to act as kind of a "master" to our github account. Everytime you push something to the internal repo, the github repo gets automatically synced and overwritten.
I like the github interface and everything around it, but it's only used for convenience to have more pretty interfaces and some basic external bug tracker and people have the possibility to send pull requests and everything, but in the end the real work is done on the internal git server.
So it doesn't have to be a all-or-nothing approach as you correctly pointed out, and we could still stick with git.sip-router.org as our main server and just hook up github as a "slave" for people preferring that interface to not be solely dependent on the availability of github.
Andreas
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@sipwise.com wrote:
Hi,
On 08/30/2013 03:08 PM, Daniel-Constantin Mierla wrote:
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.
We're doing it the other way around at Sipwise: we've our own internal git server with the standard web interface etc., but it's configured to act as kind of a "master" to our github account. Everytime you push something to the internal repo, the github repo gets automatically synced and overwritten.
I like the github interface and everything around it, but it's only used for convenience to have more pretty interfaces and some basic external bug tracker and people have the possibility to send pull requests and everything, but in the end the real work is done on the internal git server.
So it doesn't have to be a all-or-nothing approach as you correctly pointed out, and we could still stick with git.sip-router.org as our main server and just hook up github as a "slave" for people preferring that interface to not be solely dependent on the availability of github.
Andreas
______________________________**_________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**devhttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
On 08/30/2013 11:52 AM, Peter Dunkley wrote:
I don't think it does any harm for someone to ask these kinds of questions from time-to-time
Certainly, and I hope none of the responses were construed as a desire by anyone to quash discussion.
30 aug 2013 kl. 17:52 skrev Peter Dunkley peter.dunkley@crocodilertc.net:
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.
+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
Regards,
Peter
On 30 August 2013 15:58, Andreas Granig agranig@sipwise.com wrote: Hi,
On 08/30/2013 03:08 PM, Daniel-Constantin Mierla wrote: 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.
We're doing it the other way around at Sipwise: we've our own internal git server with the standard web interface etc., but it's configured to act as kind of a "master" to our github account. Everytime you push something to the internal repo, the github repo gets automatically synced and overwritten.
I like the github interface and everything around it, but it's only used for convenience to have more pretty interfaces and some basic external bug tracker and people have the possibility to send pull requests and everything, but in the end the real work is done on the internal git server.
So it doesn't have to be a all-or-nothing approach as you correctly pointed out, and we could still stick with git.sip-router.org as our main server and just hook up github as a "slave" for people preferring that interface to not be solely dependent on the availability of github.
Andreas
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Peter Dunkley Technical Director Crocodile RCS Ltd _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden
On 8/30/13 5:57 PM, Olle E. Johansson wrote:
30 aug 2013 kl. 17:52 skrev Peter Dunkley <peter.dunkley@crocodilertc.net mailto:peter.dunkley@crocodilertc.net>:
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.
+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?
Definitely and we always welcomed such discussions.
My initial remark was just to set context that just generic statements should now weight substantially at this moment. I'm for try and decide later, based on direct experiences, rather that rush and then have to revert or live with a more complex situation. And I proposed a gradual approach, it does not mean it has to be that one.
Andreas had also good remarks/suggestions and can be (part of) the solution for a while. Still someone will have to do a bit of work... volunteers?
Cheers, Daniel
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@gmail.com wrote:
On 8/30/13 5:57 PM, Olle E. Johansson wrote:
30 aug 2013 kl. 17:52 skrev Peter Dunkley <peter.dunkley@crocodilertc.net
:
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.
+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?
Definitely and we always welcomed such discussions.
My initial remark was just to set context that just generic statements should now weight substantially at this moment. I'm for try and decide later, based on direct experiences, rather that rush and then have to revert or live with a more complex situation. And I proposed a gradual approach, it does not mean it has to be that one.
Andreas had also good remarks/suggestions and can be (part of) the solution for a while. Still someone will have to do a bit of work... volunteers?
Cheers, Daniel
-- Daniel-Constantin Mierla - http://www.asipto.comhttp://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 -
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
2013/8/30 Daniel-Constantin Mierla miconda@gmail.com:
Andreas had also good remarks/suggestions and can be (part of) the solution for a while. Still someone will have to do a bit of work... volunteers?
I can try to help with the github mirror.
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:
- The GitHub concept of forking would make individual developers branches easier to manage.
How so? (I am not familiar with the GitHub concept of forking.)
- 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.
Admittedly, that would be attractive.
- 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.
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?
- 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.
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.
- There would be no need for anyone to spend time or money maintaining/patching/fixing the SIP Router Git repo and flyspray.
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.
- Someone else is handling backups and failure recovery.
Somehow I suspect that is also the case currently.
- The use of markdown means that documentation and code can be presented together in a nice way with GitHub.
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
Am Freitag, 30. August 2013, 08:42:56 schrieb Alex Balashov:
[..]
Hello,
as one of the guys who do the maintaince of sip-router.org I'll like to add my thoughts as well.
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.
We're running indeed some custom services on sip-router.org, like the generation of documentation from code, from docbook, from serctl/ sercmd object files and other stuff. There is also a daily snap shot generation, which we probably like to keep as github removed the possibility to upload and download files some time ago [1]. This stuff still needs to be run and maintained from us even after a move of the git repository.
Still, it's always a trade-off when switching to a "cloud" service. Control is good. [...]
I'd like to second this with that article:
http://redmonk.com/dberkholz/2013/04/22/the-size-of-open-source-communities-...
It looks (among other topics) to the choice of hosting provider at open source projects at the end of the article. If a project reached a certain size, they tend to move away from github.
I've nothing against a move to github per se, but we'll still need to run sip-router.org and kamailio.org, if only for our webpage and release file hosting.
Best regards,
Henning
On 08/30/2013 09:04 AM, Henning Westerholt wrote:
We're running indeed some custom services on sip-router.org, like the generation of documentation from code, from docbook, from serctl/ sercmd object files and other stuff. There is also a daily snap shot generation, which we probably like to keep as github removed the possibility to upload and download files some time ago [1]. This stuff still needs to be run and maintained from us even after a move of the git repository.
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
Am Freitag, 30. August 2013, 09:06:11 schrieb Alex Balashov:
We're running indeed some custom services on sip-router.org, like the generation of documentation from code, from docbook, from serctl/ sercmd object files and other stuff. There is also a daily snap shot generation, which we probably like to keep as github removed the possibility to upload and download files some time ago [1]. This stuff still needs to be run and maintained from us even after a move of the git repository.
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?
Surely this can be done with a read-only clone of the repository. I presented that argument more to show that we don't save IMHO that much time if we move only the git repository, and still need the rest of the infrastructure - as this was before also discussed as a benefit of a move.
Best regards,
Henning Westerholt
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:
On 08/30/2013 09:04 AM, Henning Westerholt wrote:
We're running indeed some custom services on sip-router.org, like the generation of documentation from code, from docbook, from serctl/ sercmd object files and other stuff. There is also a daily snap shot generation, which we probably like to keep as github removed the possibility to upload and download files some time ago [1]. This stuff still needs to be run and maintained from us even after a move of the git repository.
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?
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
Hello,
2013/8/30 Daniel-Constantin Mierla miconda@gmail.com:
On 8/30/13 3:06 PM, Alex Balashov 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?
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 :-)
I've tested the way we at sipwise use github as a read-only mirror [0]. And seems easy enough to use it.
Can you, please give me access to the machine that has the git repository in order to configure this? [1]
Cheers, Victor
[0] https://github.com/kamailio/kamailio_test [1] http://lists.sip-router.org/pipermail/sr-dev/2013-October/021836.html
Hello,
o Peter Dunkley on 08/29/2013 05:15 PM:
Would there be any mileage in considering a move to GitHub for the repository at the same time?
it might have changed in the meantime, but last I used GH I found email notifications lacking a lot in configurability. For example, would get only one email per push, not one per commit, format not really configurable etc. Possibly you are not supposed to use emails from GH directly.
Stefan
-
Alex Balashov -
Alexandr S. Dubovikov -
Andreas Granig -
Carlos Ruiz Díaz -
Daniel-Constantin Mierla -
Henning Westerholt -
Olle E. Johansson -
Peter Dunkley -
Richard Brady -
Stefan Sayer -
Victor Seva