

Django is now (officially) on GitHub - philipn
https://github.com/django/django

======
sho_hn
I still find it terribly ironic that a free _D_ SCM 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.

~~~
gardarh
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.

~~~
sho_hn
> I can't really see how github could ever lock in their customers

Really? It's easy: Add an additional service that doesn't store its data in
git repositories and doesn't allow for that data to be exported easily. Then
make it enticing by integrating it really well with the stuff you're already
using. Now you're going to think twice about migrating away, because suddenly
it's hard.

Not like it's rocket science, and it happens all the time when companies find
themselves in a corner (obviously we're talking a hypothetic scenario here).
Heck, it even happens with initial good intentions on all sides, because a
well-integrated add-on may be a lovely thing by itself.

I really don't want to be panicmongering, but if you "can't really see a way"
you're not cynical enough. Don't stop thinking at "it's a DSCM, we'll be
safe". You're not using git, you're using GitHub. That's why you're there,
right?

~~~
flixic
GitHub Issues. Pull Requests (and their comments). And so on.

How do you migrate this data? There's ALREADY some lock-in.

~~~
sho_hn
Well, to be fair, I think pulling out Issues is quite doable via the API right
now. Like I said, I'm not after panicmongering; I just advocate a healthy dose
of critical thinking. As in, did you _check_ you could pull out Issues via the
API before comitting to the service, and did you make sure the service vendor
is committed to offering that API going forward? If you're actually on a paid
plan, if you actually intend to make your livelyhood depend on the vendor, do
you have any hard guarantees on that in the contact? And so on.

FWIW, I was involved with putting together the git hosting infrastructure used
by the KDE community (which I wrote about at length here:
<http://news.ycombinator.com/item?id=2972107>), which incidentally was done
only after negotiations with Shortcut AS - then the company behind GitHub
competitor Gitorious.org - fell through, since we couldn't come to an
agreement acceptable to both sides. Things like data export guarantees were
part of our goals back then.

And there's more data you want to be able to export than you might think, too.
For example, if you actually let accounts push directly to your repository,
you very likely want to have logs of what account was used to push what data
for liability reasons - that's data that's not in the repo, because push !=
commit. Rather, it's data coming from the infrastructure that handles
authentication for you.

------
zzzeek
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
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
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).

------
0x006A
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> this is a
git mirror that is synced with svn

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

------
theunixbeard
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
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.)

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

------
tschellenbach
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/>

------
wrsmith
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
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
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
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-
communit...](http://jacobian.org/writing/django-community/django-
community-2012/#s-contributors)

The core team has grown a lot in 2012: 33 partial committers and 28 full
committers.

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

~~~
izak30
<https://www.djangoproject.com/weblog/2012/mar/13/py3k/>

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

~~~
tvon
What for?

------
senthilnayagam
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

~~~
fructa
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
If _anything_ , it was avoided because Git was not in Python.. But yeah.

~~~
lloeki
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-...](http://www.python.org/dev/peps/pep-0374/#why-mercurial-over-other-
dvcss)

~~~
jnoller
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
> 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/DjangoSuccessStoryBitbuc...](https://code.djangoproject.com/wiki/DjangoSuccessStoryBitbucket)

------
goronbjorn
What took so long?

~~~
mryan
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
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
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
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>

Watchers: 4,030

Forks: 753

compared to Bitbucket's:

Followers: 266

Forks: 39

So the raw numbers are dramatically in Github's favour.

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

~~~
rbanffy
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.

------
rmc
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.

~~~
espeed
"GitHub migration done!"
[https://groups.google.com/forum/?fromgroups#!topic/django-
de...](https://groups.google.com/forum/?fromgroups#!topic/django-developers/9
--P57ezyBs)

