I don't see what difference having a git.php.net repo vs a github one will make. It's the same vcs...
Instead we seriously considered the open source alternative Gitorious.org for a while, but ultimately were unable to come to an agreement with Shortcut AS with regard to a satisfactory hosting plan, and also had troubles making its ACL system work for our needs in some exploratory migrations to the platform.
Self-hosting the Gitorious software also fell out of the running fairly quickly due to the ACL problems and other concerns about the software's features and implementation; while KDE probably would have been able to put together a squad of coders to work on the software in its interest, Shortcut at the time had failed to get a dev community around Gitorious off the ground and was unacceptably slow at processing merge requests - meaning a fork might have become necessary, which is always an icky proposition not to mention a big burden on resources.
Ultimately we ended up banging together our own Git infrastructure out of several smaller components, some of which we wrote ourselves:
* To handle access controls as well as the developer-facing repo management knobs (personal server-side clones, personal scratch repos, access management for those, a trashcan for repos, the works) we chose gitolite, which was definitely the best choice we could have made. It's reliable, well-documented, fast and rich in features, and its principal developer Sitaram Chamarty has been an incredible aid to our efforts both with many hours of work spent coding additional features we needed and tons of advice. We did write a couple of add-ins to gitolite ourselves to provide some additional commands to developers, which we found pleasant to do.
* As web-based repository viewer we use an inhouse-modified version of Redmine. As with gitolite, we've found the Redmine crew to be easy to approach and get help from, and while we ran into some trouble with the scalability of its Git support, it proved easy enough to modify without requiring massive forking. Redmine's database of projects serves a vital role in the system in that the gitolite config is generated from Redmine's database (e.g user access roles), and we also generate a custom-format XML from it that is used by end-user clone/build tools, our translation infrastructure, LXR and many other bits and pieces that have a need to discover projects and repositories and their metadata (which can be modified by project managers in the Redmine web UI, e.g. setting description texts or translation branches).
* For review, we use ReviewBoard, continuing on from SVN. This is definitely the weak spot in our setup right now; ReviewBoard just doesn't support Git very well since it's designed to handle single patches rather than series of them and thus also can't track branches. We've been looking at Gerrit on and off to replace it, but so far can't really bring ourselves to commit to it since it's a fairly unwieldy beast.
* We wrote our own repository hooks in Python, which are in charge of things like sending out commit mails to mailing lists, CIA.vc, the bug tracker and people mentioned in commit messages behind special keywords, evaluating other keywords to close bug tickets or review requests, check for trivial errors (EOL style, license headers, that sort of thing), ref backups and a bunch of other tasks. Some of which run through asynchronous job queues as required to avoid blocking.
* We wrote our own mirroring system to provide several read-only git:// mirror servers behind a geo-ip DNS load balancer. The mirrors get updated whenever a push to the master happens.
* KDE has an LDAP-based single sign-on system in use at many of its web properties including Redmine and ReviewBoard, currently using an inhouse-modified (mostly expanded with our own modules) version of GOsa as web frontend. GOsa is also used to request developer privileges and manage the SSH keys for Git write access.
* There are a couple of other minor bits and pieces flying about, like a commits.kde.org/<repoid/<abbreviated or full sha1> web app written in Ruby+Sinatra that forwards to the Redmine page for the commit; those URLs pop up in various places, e.g. in a developer's terminal output after pushing, in mail headers, CIA.vc postings, etc.
KDE's migration to Git is still ongoing, with many large and actively developed codebases still remaining in SVN at this time, as well as the entire translation effort. To actually migrate things we use our own tool called svn2git which takes raw SVN repo data, an account conversion map (supplied as plain text generated from our LDAP) and a plain text file with regex-based rules as input and produces git repositories. Writing the necessary rules files is unfortunately a time-intensive task especially given some very complex project histories originally imported from CVS, but additional tools exist to partially auto-generate them by analyzing SVN history programmatically.
Here's a couple of links of interest:
* The developer-facing user manual for KDE's Git infra: http://community.kde.org/Sysadmin/GitKdeOrgManual
* The initial posting of the sysadmin working group's plan for the above setup, and our evaluation of this stack vs. the Gitorious software (ODF of the latter is attached to the first reply): http://mail.kde.org/pipermail/kde-scm-interest/2010-June/001...
* The XML export from Redmine mentioned above: https://projects.kde.org/kde_projects.xml
[1] Unless you count mirrors, in which case both Linux and PHP are on github.
It's as simple to commit projects to github as it is to sf, bitbucket, google code, etc. Wait... you need to set up ssh credentials on github... sorry, it's more difficult to commit a project to github than it is to most of the alternatives.
>Also love the idea of a centralized place to follow all your favorite projects.
It's good that we like different things. I love the FACT that there can't be such place, it's technically not possible, fortunately!
>If linux can be on github i would think php could as well.
Linux is not on github, Linus Torvalds has one of his branches of the linux kernel on github, doesn't mean that he doesn't push his commits to other places too, which he certainly does. Also, linux is much more than the kernel, and its bits are hosted in literally thousands of different places. Finally, you can maintain your branch of the linux kernel wherever you wish, there's no mystical force forcing everybody to use Linus', you can use whatever kernel build you want from whatever sources you want. So saying "linux is on github" is a rather vague sentence.
Don't get me wrong, I like github, I would hate not having a reason to. It appears to me that most of the people don't relaly know why they like github. Because it's popular maybe?
Therein lies the problem, and why it's not a good collaboration space for everyone (as has been implied elsewhere in this thread). I won't use it simply because I dislike dealing with git, for example. Yes, it's a great tool if you want to use git. The mentality I've seen become more prevalent over the last year to two years, however, is that you must be on Github to "do open source right"--setting aside the obvious silliness of that, it does still exist in a lot of places.
If they supported hg with the same infrastructure, I'd consider switching off of bitbucket, but given the Github folks' public behaviors in the past, it wouldn't be a guarantee. I've been treated very well by Atlassian and don't think particularly highly of the Github guys.
You can just as easily use it over HTTPS and use your github login (which is how a lot of SVN repos are setup).
SF, BitBucket, Google Code, et. all are no easier or harder than GitHub for getting access. You have to register for all of them and setup your credentials for the repo on all of them.
:)