7 ms·

Django is now (officially) on GitHub

276 points by philipn 14y ago

senthilnayagam 14y ago
good to see django on github hey dowvoters i am not a troll, many python projects avoided github initially because github was powered by ruby, see it in context chef, puppet,vagrant,heroku are of ruby origin but now loved by people from various technology backgrounds
- detst 14y ago
  I didn't see your original comment but if it was just "good to see django on github", you were downvoted for not adding anything to the conversation. Your edit is better.
- fructa 14y ago
  Your conjecture that GitHub was initially avoided by people who don't use Ruby because it's written in Ruby is pointlessly divisive and quite silly.
  - lamby 14y ago
    If anything, it was avoided because Git was not in Python.. But yeah.
    - lloeki 14y ago
      From PEP-0374 [0]: > Lastly, all things being equal (which they are not as shown by the previous two issues), it is preferable to use and support a tool written in Python and not one written in C and shell. Okay this pertains to Python itself but could easily have mattered to Django. [0] http://www.python.org/dev/peps/pep-0374/#why-mercurial-over-other-dvcss http://www.python.org/dev/peps/pep-0374/#why-mercurial-over-...
      - jnoller 14y ago
        Note that this is python-core - which has an obvious python bias for a variety of reasons, and also doesn't pertain in any way to github (see the fact they self-host HG). In actuality, having HG be written in python has helped python-core write plugins and resolve other issues. So; in summation pick the right tool for your team not due to some techno bigotry, which is what that PEP outlines.
        lloeki 14y ago
        > in summation pick the right tool for your team Precisely and I was not saying otherwise. The Python team chose hg partly (but not only) because it is written with Python, just as the Django team could have decided to choose Bitbucket partly because it is written with Django[0]. And they could have chosen hg partly because it is written with python, or chosen git (which they did), as both were supported by Bitbucket. Whatever, I'm not saying they should have, just that they could, and that dogfooding is a valid point if it is not blindly overrated (i.e bigotry) but carefully considered. [0] https://code.djangoproject.com/wiki/DjangoSuccessStoryBitbucket https://code.djangoproject.com/wiki/DjangoSuccessStoryBitbuc...
    - lucian1900 14y ago
      Especially since hg exists, is extremely similar to Git and arguably has a better UI.
  - senthilnayagam 14y ago
    I don't have any damning evidence to win a lawsuit :) but would still make a attempt to give empirical evidence Tiobe 2012 report http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html http://www.tiobe.com/index.php/content/paperinfo/tpci/index.... https://github.com/languages https://github.com/languages Javascript is 9th and Ruby in 11th for popularity on tiobe but take first and second rank on github open source projects I understand not all pre-github projects have moved from sourceforge and google code, but even for newer projects people have biases for technology choices
    - deleted 14y ago
      [deleted]
- human_error 14y ago
  > many python projects avoided github initially because github was powered by ruby This doesn't make any sense. Don't tell me that there are C# developers who don't use Google because they use Java.
  - streptomycin 14y ago
    It would make sense a little bit if GitHub was open source.
wrsmith 14y ago
Interested in the history of the project...was it simply on SVN all this time? Or were there other issues that held up its migration onto Github?
- oinopion 14y ago
  For long time core devs wanted to use support the common denominator (svn) and let users choose their frontend (hg-svn, git-svn, svk). Now they realised that github presence will raise number of contributors.
  - reinhardt 14y ago
    I stopped following Django more than a year ago but lack of contributors was never an issue; quite the contrary. A bigger problem was the unresponsiveness of the (tiny) core team to the occasional contributors providing patches and raising bugs, often left open for months and years. Hopefully things move faster now with more devs being entrusted with the commit bit.
    - huxley 14y ago
      I hope it will too. Particularly now that Adrian Holovaty is back as a more active BDFL. Jacob Kaplan-Moss (the other BDFL) wrote a bit about the changes in the core team over the last couple of years in his "Measuring the Django Community" review: http://jacobian.org/writing/django-community/django-community-2012/#s-contributors http://jacobian.org/writing/django-community/django-communit... The core team has grown a lot in 2012: 33 partial committers and 28 full committers.
whalesalad 14y ago
This is incredibly awesome. Very excited about this. Hopefully we'll see more cool stuff getting merged in via pull requests.
goronbjorn 14y ago
What took so long?
- mryan 14y ago
  I can't speak for any of the core Django team, but as a user of Django I am glad that they took their time with this one. IMO github 'won' the social coding and source hosting battle a while ago, but I am glad that the Django team don't immediately jump to the new hot thing. There are a lot of things to consider with such a move, and moving too quickly would be a disservice to Django users. Having said that, I am very glad they have moved. I think the previous Trac/SVN setup had more friction in terms of submitting, reviewing and accepting commits. Hopefully github will make this process more fluid.
  - jolohaga 14y ago
    Interesting. I didn't know Django was on SVN until now. Why didn't they choose Bitbucket? I think it could have been as productive as Github.
    - huxley 14y ago
      From following the discussion, the impression I got was that more core developers and contributors were using Github. Beyond the "key user" metric, the raw numbers also seem to lean in favour Github: there are 665 watchers on Github, 266 followers on Bitbucket; 56 forks on Github, 39 on Bitbucket.
      - huxley 14y ago
        Just an addendum to the Github numbers, I hadn't realized Adrian Holovaty had renamed the previous Github repository to django-old, replacing it with the brand new repository (with the SVN history, etc). So if you look at django-old's numbers: https://github.com/django/django-old https://github.com/django/django-old Watchers: 4,030 Forks: 753 compared to Bitbucket's: Followers: 266 Forks: 39 So the raw numbers are dramatically in Github's favour.
philcoders 14y ago
This is great!, Now just waiting for the announced python 3 support in the next version (1.5) and were all set!
- izak30 14y ago
  https://www.djangoproject.com/weblog/2012/mar/13/py3k/ https://www.djangoproject.com/weblog/2012/mar/13/py3k/
theunixbeard 14y ago
It seems GitHub is certainly king now... But how long will it last? I feel that Version Control is such a great market that surely some significant challengers will appear in the next few years. Thoughts?
- yyyt 14y ago
  They'll have to invent something really new or have an uphill battle, because GitHub now relies a lot on network externality. In simple words, it is the effect that you chose a popular network for the number of projects on it. I do submit bug reports to projects on BitBucket and GitHub, and not to private bugzillas/tracs (I'm tired of registering and confirming every time.)
  - deleted 14y ago
    [deleted]
- lstoll 14y ago
  I think if a new 'leader' in version control systems starts to make ground, github could easily adapt and support it. The github magic isn't just git, it's the network and collaboration tooling around your code.
  - human_error 14y ago
    GitHub makes very easy to collaborate to projects. I think that what makes them different than others such as BitBucket.
- IsTom 14y ago
  I can't find it right now, but some time ago I've read in a darcs vs git comparison that depending on orders of patches git can sometimes yield two different results. Perhaps in future correctness in huge procjects will be an issue.
  - krschultz 14y ago
    How many source code bases are larger and have more authors than the linux kernel?
deleted 14y ago
[deleted]
deleted 14y ago
[deleted]
0x006A 14y ago
looking at djangoproject.com they still use svn, the github repository also does not contain any of the release branches. has there been any announcement about a migration to git? according to https://code.djangoproject.com/wiki/DjangoBranches https://code.djangoproject.com/wiki/DjangoBranches this is a git mirror that is synced with svn
- 0x006A 14y ago
  to answer my own question, https://groups.google.com/forum/?fromgroups#!topic/django-developers/9--P57ezyBs https://groups.google.com/forum/?fromgroups#!topic/django-de... has more details, for now indeed only trunk is migrated, at least release tags would be nice to migrate over.
rmc 14y ago
Misleading title, I've flagged this. This is an offical branch of Django on git, this github branch has been around for a while. The offical Django development is still on svn.
- stricken 14y ago
  It looks official: https://code.djangoproject.com/ https://code.djangoproject.com/ "Django uses Git (git) for managing its code."
  - rmc 14y ago
    Ah OK. Whoops my bad.
- espeed 14y ago
  "GitHub migration done!" https://groups.google.com/forum/?fromgroups#!topic/django-developers/9--P57ezyBs https://groups.google.com/forum/?fromgroups#!topic/django-de...
  - rmc 14y ago
    Ah OK. Whoops my bad.
sho_hn 14y ago
I still find it terribly ironic that a free DSCM wound up at the heart of such a massive drive toward proprietary centralization. I think a lot of people envisioned things heading in a rather different direction. Which is not meant as backhanded flame of GitHub's product, by the way. Rather, as far as observations go, it can only speak to the opposite - given that everybody can roll their own, they may be doing something right. OTOH, I think it does call for vigilence on whether they're going to start adding lock-in systems, unless they have already.
- scorpion032 14y ago
  This centralization has occurred out of different people's individual choice and so it is quite different from any other centralized system.
  - reinhardt 14y ago
    More to the point, even if decentralization is not widespread now, it's a great insurance that will come handy when GitHub stops being such a compelling choice.
- gardarh 14y ago
  The big benefit about DSCM is by definitions that they are in fact very portable so I don't think this is an issue. I can't really see how github could ever lock in their customers, if their product becomes inferior to others the switch will always be very painless.
  - mryan 14y ago
    Exactly. If it ever becomes necessary to move away from github, it can be done in seconds by adding a new remote and pushing. I have always seen this as a testament to github's quality - if the switching cost to your users is a couple of shell commands, you better make sure you offer a good product! I also keep my projects in a local gitosis repository, mainly so I'm not relying on github as part of my deploy flow.
  - sho_hn 14y ago
tschellenbach 14y ago
Nice, really happy about this. Hopefully our patches will finally get to go through. If you're in Europe and working with Django have a look at our Job openings, http://djangogigs.com/gigs/1182/ http://djangogigs.com/gigs/1182/
jolohaga 14y ago
Couldn't ignore the irony. Github is a Rails application.
- hcarvalhoalves 14y ago
  And Git is not Python either. What's your point?
- rbanffy 14y ago
  All the Pythonistas I know are very pragmatic WRT programming languages and frameworks. I see no real difference between Rails and Django - they both solve very similar problems in very similar ways. And they are both, certainly, good enough. I can have long discussions about the merits of buildout (I call it Python's Maven), but it's much more for practicing the almost-lost art of debate than for anything else. It all boils down to taste. I don't use HN because it's written in ARC - I come for the discussions.
stu_wilson 14y ago
Why can't Opens Source Orgs roll an independent repo hosting server with something like GitLab (gitlabhq.com)?
- tvon 14y ago
  What for?
zzzeek 14y ago
Big problems with older projects that want to move to GitHub. GitHub's bug reporting API has no means of importing bugs from other systems, without losing all date and user information. Projects that have moved their issue systems over have the full expanse of issues all opened/resolved on the same date and by the same person, and are basically unreadable (sorry, comments with the original info in them don't count). Django in this case is keeping trac for issue reporting. I've emailed github about this, and I got kind of a sleepy "no, we don't really do that, shrugs". I had an insight at that moment, that Github probably does this because they don't want big, ugly old projects moving their 8000 big ugly tickets into their shiny system (Edit: but they've just responded that they want to do this! so, great). My inspiration to move SQLAlchemy to github went to zero in an instant. Fuck that. Old projects and old history about projects matter. A lot. Keeping issue reporting on Trac - AFAICT, Django hasn't solved the issue of coordinate changeset links from trac back to an external service like github. They still seem to have their SVN repo linked in trac. Though this could be solved, with a fair degree of tedium, by first converting all the SVN links in their bug reports to be the equivalent changeset id in git, then hosting a mirror of the git repo. I originally did this when we moved from SVN to mercurial.
- technoweenie 14y ago
  We have an early alpha program if you want to import your tickets to GitHub. We helped move Parrot (and a few others) over. Contact support@github.com.
  - zzzeek 14y ago
    sounds great. Will there be an open API ? I'm not in a hurry, I'll wait til it's up for real. It just needs to accept timestamps for all tickets/comments/updates and allow the owners of tickets/comments/updates to be github names (which might be a thorny security issue).

276 points by philipn 14y ago

good to see django on github hey dowvoters i am not a troll, many python projects avoided github initially because github was powered by ruby, see it in context chef, puppet,vagrant,heroku are of ruby origin but now loved by people from various technology backgrounds

detst 14y ago
I didn't see your original comment but if it was just "good to see django on github", you were downvoted for not adding anything to the conversation. Your edit is better.
fructa 14y ago
Your conjecture that GitHub was initially avoided by people who don't use Ruby because it's written in Ruby is pointlessly divisive and quite silly.
- lamby 14y ago
  If anything, it was avoided because Git was not in Python.. But yeah.
  - lloeki 14y ago
    From PEP-0374 [0]: > Lastly, all things being equal (which they are not as shown by the previous two issues), it is preferable to use and support a tool written in Python and not one written in C and shell. Okay this pertains to Python itself but could easily have mattered to Django. [0] http://www.python.org/dev/peps/pep-0374/#why-mercurial-over-other-dvcss http://www.python.org/dev/peps/pep-0374/#why-mercurial-over-...
    - jnoller 14y ago
      Note that this is python-core - which has an obvious python bias for a variety of reasons, and also doesn't pertain in any way to github (see the fact they self-host HG). In actuality, having HG be written in python has helped python-core write plugins and resolve other issues. So; in summation pick the right tool for your team not due to some techno bigotry, which is what that PEP outlines.
      - lloeki 14y ago
        > in summation pick the right tool for your team Precisely and I was not saying otherwise. The Python team chose hg partly (but not only) because it is written with Python, just as the Django team could have decided to choose Bitbucket partly because it is written with Django[0]. And they could have chosen hg partly because it is written with python, or chosen git (which they did), as both were supported by Bitbucket. Whatever, I'm not saying they should have, just that they could, and that dogfooding is a valid point if it is not blindly overrated (i.e bigotry) but carefully considered. [0] https://code.djangoproject.com/wiki/DjangoSuccessStoryBitbucket https://code.djangoproject.com/wiki/DjangoSuccessStoryBitbuc...
  - lucian1900 14y ago
    Especially since hg exists, is extremely similar to Git and arguably has a better UI.
- senthilnayagam 14y ago
  I don't have any damning evidence to win a lawsuit :) but would still make a attempt to give empirical evidence Tiobe 2012 report http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html http://www.tiobe.com/index.php/content/paperinfo/tpci/index.... https://github.com/languages https://github.com/languages Javascript is 9th and Ruby in 11th for popularity on tiobe but take first and second rank on github open source projects I understand not all pre-github projects have moved from sourceforge and google code, but even for newer projects people have biases for technology choices
  - deleted 14y ago
    [deleted]
human_error 14y ago
> many python projects avoided github initially because github was powered by ruby This doesn't make any sense. Don't tell me that there are C# developers who don't use Google because they use Java.
- streptomycin 14y ago
  It would make sense a little bit if GitHub was open source.

wrsmith 14y ago

Interested in the history of the project...was it simply on SVN all this time? Or were there other issues that held up its migration onto Github?

oinopion 14y ago
For long time core devs wanted to use support the common denominator (svn) and let users choose their frontend (hg-svn, git-svn, svk). Now they realised that github presence will raise number of contributors.
- reinhardt 14y ago
  I stopped following Django more than a year ago but lack of contributors was never an issue; quite the contrary. A bigger problem was the unresponsiveness of the (tiny) core team to the occasional contributors providing patches and raising bugs, often left open for months and years. Hopefully things move faster now with more devs being entrusted with the commit bit.
  - huxley 14y ago
    I hope it will too. Particularly now that Adrian Holovaty is back as a more active BDFL. Jacob Kaplan-Moss (the other BDFL) wrote a bit about the changes in the core team over the last couple of years in his "Measuring the Django Community" review: http://jacobian.org/writing/django-community/django-community-2012/#s-contributors http://jacobian.org/writing/django-community/django-communit... The core team has grown a lot in 2012: 33 partial committers and 28 full committers.

whalesalad 14y ago

This is incredibly awesome. Very excited about this. Hopefully we'll see more cool stuff getting merged in via pull requests.

goronbjorn 14y ago

What took so long?

mryan 14y ago
I can't speak for any of the core Django team, but as a user of Django I am glad that they took their time with this one. IMO github 'won' the social coding and source hosting battle a while ago, but I am glad that the Django team don't immediately jump to the new hot thing. There are a lot of things to consider with such a move, and moving too quickly would be a disservice to Django users. Having said that, I am very glad they have moved. I think the previous Trac/SVN setup had more friction in terms of submitting, reviewing and accepting commits. Hopefully github will make this process more fluid.
- jolohaga 14y ago
  Interesting. I didn't know Django was on SVN until now. Why didn't they choose Bitbucket? I think it could have been as productive as Github.
  - huxley 14y ago
    From following the discussion, the impression I got was that more core developers and contributors were using Github. Beyond the "key user" metric, the raw numbers also seem to lean in favour Github: there are 665 watchers on Github, 266 followers on Bitbucket; 56 forks on Github, 39 on Bitbucket.
    - huxley 14y ago
      Just an addendum to the Github numbers, I hadn't realized Adrian Holovaty had renamed the previous Github repository to django-old, replacing it with the brand new repository (with the SVN history, etc). So if you look at django-old's numbers: https://github.com/django/django-old https://github.com/django/django-old Watchers: 4,030 Forks: 753 compared to Bitbucket's: Followers: 266 Forks: 39 So the raw numbers are dramatically in Github's favour.

philcoders 14y ago

This is great!, Now just waiting for the announced python 3 support in the next version (1.5) and were all set!

izak30 14y ago
https://www.djangoproject.com/weblog/2012/mar/13/py3k/ https://www.djangoproject.com/weblog/2012/mar/13/py3k/

theunixbeard 14y ago

It seems GitHub is certainly king now... But how long will it last? I feel that Version Control is such a great market that surely some significant challengers will appear in the next few years. Thoughts?

yyyt 14y ago
They'll have to invent something really new or have an uphill battle, because GitHub now relies a lot on network externality. In simple words, it is the effect that you chose a popular network for the number of projects on it. I do submit bug reports to projects on BitBucket and GitHub, and not to private bugzillas/tracs (I'm tired of registering and confirming every time.)
- deleted 14y ago
  [deleted]
lstoll 14y ago
I think if a new 'leader' in version control systems starts to make ground, github could easily adapt and support it. The github magic isn't just git, it's the network and collaboration tooling around your code.
- human_error 14y ago
  GitHub makes very easy to collaborate to projects. I think that what makes them different than others such as BitBucket.
IsTom 14y ago
I can't find it right now, but some time ago I've read in a darcs vs git comparison that depending on orders of patches git can sometimes yield two different results. Perhaps in future correctness in huge procjects will be an issue.
- krschultz 14y ago
  How many source code bases are larger and have more authors than the linux kernel?

deleted 14y ago

[deleted]

deleted 14y ago

[deleted]

0x006A 14y ago

looking at djangoproject.com they still use svn, the github repository also does not contain any of the release branches. has there been any announcement about a migration to git? according to https://code.djangoproject.com/wiki/DjangoBranches https://code.djangoproject.com/wiki/DjangoBranches this is a git mirror that is synced with svn

0x006A 14y ago
to answer my own question, https://groups.google.com/forum/?fromgroups#!topic/django-developers/9--P57ezyBs https://groups.google.com/forum/?fromgroups#!topic/django-de... has more details, for now indeed only trunk is migrated, at least release tags would be nice to migrate over.

rmc 14y ago

Misleading title, I've flagged this. This is an offical branch of Django on git, this github branch has been around for a while. The offical Django development is still on svn.

stricken 14y ago
It looks official: https://code.djangoproject.com/ https://code.djangoproject.com/ "Django uses Git (git) for managing its code."
- rmc 14y ago
  Ah OK. Whoops my bad.
espeed 14y ago
"GitHub migration done!" https://groups.google.com/forum/?fromgroups#!topic/django-developers/9--P57ezyBs https://groups.google.com/forum/?fromgroups#!topic/django-de...
- rmc 14y ago
  Ah OK. Whoops my bad.

sho_hn 14y ago

I still find it terribly ironic that a free DSCM wound up at the heart of such a massive drive toward proprietary centralization. I think a lot of people envisioned things heading in a rather different direction. Which is not meant as backhanded flame of GitHub's product, by the way. Rather, as far as observations go, it can only speak to the opposite - given that everybody can roll their own, they may be doing something right. OTOH, I think it does call for vigilence on whether they're going to start adding lock-in systems, unless they have already.

scorpion032 14y ago
This centralization has occurred out of different people's individual choice and so it is quite different from any other centralized system.
- reinhardt 14y ago
  More to the point, even if decentralization is not widespread now, it's a great insurance that will come handy when GitHub stops being such a compelling choice.
gardarh 14y ago
The big benefit about DSCM is by definitions that they are in fact very portable so I don't think this is an issue. I can't really see how github could ever lock in their customers, if their product becomes inferior to others the switch will always be very painless.
- mryan 14y ago
  Exactly. If it ever becomes necessary to move away from github, it can be done in seconds by adding a new remote and pushing. I have always seen this as a testament to github's quality - if the switching cost to your users is a couple of shell commands, you better make sure you offer a good product! I also keep my projects in a local gitosis repository, mainly so I'm not relying on github as part of my deploy flow.
- sho_hn 14y ago

tschellenbach 14y ago

Nice, really happy about this. Hopefully our patches will finally get to go through. If you're in Europe and working with Django have a look at our Job openings, http://djangogigs.com/gigs/1182/ http://djangogigs.com/gigs/1182/

jolohaga 14y ago

Couldn't ignore the irony. Github is a Rails application.

hcarvalhoalves 14y ago
And Git is not Python either. What's your point?
rbanffy 14y ago
All the Pythonistas I know are very pragmatic WRT programming languages and frameworks. I see no real difference between Rails and Django - they both solve very similar problems in very similar ways. And they are both, certainly, good enough. I can have long discussions about the merits of buildout (I call it Python's Maven), but it's much more for practicing the almost-lost art of debate than for anything else. It all boils down to taste. I don't use HN because it's written in ARC - I come for the discussions.

stu_wilson 14y ago

Why can't Opens Source Orgs roll an independent repo hosting server with something like GitLab (gitlabhq.com)?

tvon 14y ago
What for?

zzzeek 14y ago

Big problems with older projects that want to move to GitHub. GitHub's bug reporting API has no means of importing bugs from other systems, without losing all date and user information. Projects that have moved their issue systems over have the full expanse of issues all opened/resolved on the same date and by the same person, and are basically unreadable (sorry, comments with the original info in them don't count). Django in this case is keeping trac for issue reporting. I've emailed github about this, and I got kind of a sleepy "no, we don't really do that, shrugs". I had an insight at that moment, that Github probably does this because they don't want big, ugly old projects moving their 8000 big ugly tickets into their shiny system (Edit: but they've just responded that they want to do this! so, great). My inspiration to move SQLAlchemy to github went to zero in an instant. Fuck that. Old projects and old history about projects matter. A lot. Keeping issue reporting on Trac - AFAICT, Django hasn't solved the issue of coordinate changeset links from trac back to an external service like github. They still seem to have their SVN repo linked in trac. Though this could be solved, with a fair degree of tedium, by first converting all the SVN links in their bug reports to be the equivalent changeset id in git, then hosting a mirror of the git repo. I originally did this when we moved from SVN to mercurial.

technoweenie 14y ago
We have an early alpha program if you want to import your tickets to GitHub. We helped move Parrot (and a few others) over. Contact support@github.com.
- zzzeek 14y ago
  sounds great. Will there be an open API ? I'm not in a hurry, I'll wait til it's up for real. It just needs to accept timestamps for all tickets/comments/updates and allow the owners of tickets/comments/updates to be github names (which might be a thorny security issue).