4 ms·

i hope they'll follow the trend and move it to github!

by ranza 15y ago

irrumator 15y ago
Why?
- treffer 15y ago
  because github is one of the most visible and most visited source hosting sites?
  - skeptical 15y ago
    I still don't get your point. It's the most visited source hosting site, no doubt about that, so...? On the subject of the topic, I'm getting tired of this git euforia. The linked message says zero about the reason beyond a simple direct voting. So, for no reason they decided to have a voting and ignore the reasons why people vote whatever they did? Sounds like a pretty useless voting for me. Well, except if you want to be popular and use all the tools the cool kids use these days, I guess that's a valid reason. Something tells me that there will be less 'I'm too cool to say positive things about PHP' kind of threads in HN.
    - derekorgan 15y ago
      to be fair the reason is outlined in the post. "... move to a decentralized version control system."
      - skeptical 15y ago
        bazaar and mercurial are decentralized too, so that would only rule out SVN.
    - jarin 15y ago
      Well, I mean, there's a reason all the cool kids are using git these days, and it's not just to "look cool".
    - d0m 15y ago
      Well Git is simply great. It's fast, it's powerful, there's a very helpful community, it's integrated everywhere, there are well made and useful online repository (Yes Github, but others too), the list goes on and on. Yes, there are bazaar, mercurial and probably dozen of others, but there's also git. I'm not sure I get your point. I think what you don't like is that they chose to jump on git without real reason instead of carefully comparing other alternatives. It might be true.. or it might not. All great programmers try various version control.. if the majority of them prefered Git for their personal projects, why not switch to it? And, for open source project, Github is really just too useful.
      - skeptical 15y ago
        My point is rather simple: Everybody is jumping in the git/github bandwagen but the huge majority doesn't appear to be able to state practical advantage of git besides github popularity. That is my point. Not saying that there are no advantages, but heck, changing to something else because "it should be good, everyone else is doing it" is plain stupid... and very silly. And those are attributes we wouldn't want to welcome to the hackers' community.
        armandososa 15y ago
        ever heard of the network effect?
        rimantas 15y ago
        Who are "we"? Someone making assumptions about the motivation of others? the huge majority doesn't appear to be able How do you know that? Did you interview the huge majority yourself? Git has many important advantages over svn and they are no secret.
    - jarofgreen 15y ago
      > The linked message says zero about the reason beyond a simple direct voting. The linked message is a single posting from thousands to an internal message list, of course it doesn't. A quick search for "git" on the PHP internals list shows lots of posts. > So, for no reason they decided to have a voting and ignore the reasons why people vote whatever they did? Jumping to conclusions much?
- ranza 15y ago
  What treffer said. It'll be like the old days of sourceforge, just better and simpler. I love how easy it is to commit to projects on github. Also love the idea of a centralized place to follow all your favorite projects. If linux can be on github i would think php could as well.
  - irrumator 15y ago
    PHP has been mirrored on github for awhile already if you want to follow it and stuff: https://github.com/php https://github.com/php I don't see what difference having a git.php.net repo vs a github one will make. It's the same vcs...
    - LeafStorm 15y ago
      True, but git.php.net would be under their control with regards to what kind of infrastructure they want to set up on it. If they hosted it on GitHub, they would have to rely on GitHub's infrastructure instead of being able to develop and maintain their own.
      - sho_hn 15y ago
        FWIW, during KDE's (one of the largest open source communities around, with about 2500 active developer accounts with direct write access to many millions of lines of code across dozens of products, and large numbers of external contributors) ongoing migration from SVN to Git, GitHub was never considered as an option because the community considers it unacceptable for an open source community to throw their weight behind a proprietary solution. 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 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/001438.html 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 https://projects.kde.org/kde_projects.xml

i hope they'll follow the trend and move it to github!

by ranza 15y ago

i hope they'll follow the trend and move it to github!

irrumator 15y ago

Why?

treffer 15y ago
because github is one of the most visible and most visited source hosting sites?
- skeptical 15y ago
  I still don't get your point. It's the most visited source hosting site, no doubt about that, so...? On the subject of the topic, I'm getting tired of this git euforia. The linked message says zero about the reason beyond a simple direct voting. So, for no reason they decided to have a voting and ignore the reasons why people vote whatever they did? Sounds like a pretty useless voting for me. Well, except if you want to be popular and use all the tools the cool kids use these days, I guess that's a valid reason. Something tells me that there will be less 'I'm too cool to say positive things about PHP' kind of threads in HN.
  - derekorgan 15y ago
    to be fair the reason is outlined in the post. "... move to a decentralized version control system."
    - skeptical 15y ago
      bazaar and mercurial are decentralized too, so that would only rule out SVN.
  - jarin 15y ago
    Well, I mean, there's a reason all the cool kids are using git these days, and it's not just to "look cool".
  - d0m 15y ago
    Well Git is simply great. It's fast, it's powerful, there's a very helpful community, it's integrated everywhere, there are well made and useful online repository (Yes Github, but others too), the list goes on and on. Yes, there are bazaar, mercurial and probably dozen of others, but there's also git. I'm not sure I get your point. I think what you don't like is that they chose to jump on git without real reason instead of carefully comparing other alternatives. It might be true.. or it might not. All great programmers try various version control.. if the majority of them prefered Git for their personal projects, why not switch to it? And, for open source project, Github is really just too useful.
    - skeptical 15y ago
      My point is rather simple: Everybody is jumping in the git/github bandwagen but the huge majority doesn't appear to be able to state practical advantage of git besides github popularity. That is my point. Not saying that there are no advantages, but heck, changing to something else because "it should be good, everyone else is doing it" is plain stupid... and very silly. And those are attributes we wouldn't want to welcome to the hackers' community.
      - armandososa 15y ago
        ever heard of the network effect?
      - rimantas 15y ago
        Who are "we"? Someone making assumptions about the motivation of others? the huge majority doesn't appear to be able How do you know that? Did you interview the huge majority yourself? Git has many important advantages over svn and they are no secret.
  - jarofgreen 15y ago
    > The linked message says zero about the reason beyond a simple direct voting. The linked message is a single posting from thousands to an internal message list, of course it doesn't. A quick search for "git" on the PHP internals list shows lots of posts. > So, for no reason they decided to have a voting and ignore the reasons why people vote whatever they did? Jumping to conclusions much?
ranza 15y ago
What treffer said. It'll be like the old days of sourceforge, just better and simpler. I love how easy it is to commit to projects on github. Also love the idea of a centralized place to follow all your favorite projects. If linux can be on github i would think php could as well.
- irrumator 15y ago
  PHP has been mirrored on github for awhile already if you want to follow it and stuff: https://github.com/php https://github.com/php I don't see what difference having a git.php.net repo vs a github one will make. It's the same vcs...
  - LeafStorm 15y ago
    True, but git.php.net would be under their control with regards to what kind of infrastructure they want to set up on it. If they hosted it on GitHub, they would have to rely on GitHub's infrastructure instead of being able to develop and maintain their own.
    - sho_hn 15y ago
      FWIW, during KDE's (one of the largest open source communities around, with about 2500 active developer accounts with direct write access to many millions of lines of code across dozens of products, and large numbers of external contributors) ongoing migration from SVN to Git, GitHub was never considered as an option because the community considers it unacceptable for an open source community to throw their weight behind a proprietary solution. 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 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/001438.html 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 https://projects.kde.org/kde_projects.xml