30 Aug
2013
30 Aug
'13
4:08 p.m.
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:
--
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 -
+1 for GitHub too
On Fri, Aug 30, 2013 at 4:27 AM, Richard Brady <rnbrady(a)gmail.com
<mailto:rnbrady@gmail.com>> wrote:
+1 for GitHub
On 29 Aug 2013, at 17:58, Peter Dunkley
<peter.dunkley(a)crocodilertc.net
<mailto:peter.dunkley@crocodilertc.net>> wrote:
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev 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
<mailto:oej@edvina.net>> wrote:
29 aug 2013 kl. 18:29 skrev Peter Dunkley
<peter.dunkley(a)crocodilertc.net
<mailto:peter.dunkley@crocodilertc.net>>:
_______________________________________________
sr-dev mailing list
sr-dev(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
* 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(a)evaristesys.com
<mailto:abalashov@evaristesys.com>> wrote:
Peter,
What do you see to be GitHub's virtues for this project?
Peter Dunkley <peter.dunkley(a)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(a)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(a)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(a)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(a)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(a)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(a)lists.sip-router.org <mailto:sr-dev@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev