

Moving Django to GitHub: the postmortem - googletron
http://www.holovaty.com/writing/django-github/

======
tetomb
I would have liked them to move to bitbucket.org because it was built with
Django.

~~~
elithrar
> I would have liked them to move to bitbucket.org because it was built with
> Django.

But Mercurial itself wasn't (although it was written mostly in Python). I
think this is a good example of taking the pragmatic choice (GitHub) over the
ideological choice (Bitbucket).

~~~
__alexs
BitBucket supports Git repositories...

~~~
mryan
That's mostly irrelevant. A lot of people are not using Github just because it
supports git - the network effect is one of the key drivers in choosing
Github.

~~~
__alexs
Certainly but that wasn't on OPs list of reasons to use it :)

~~~
dalore
Looks like it was:

> Why Git/GitHub, as opposed to Mercurial/Bitbucket or some other system?
> Because it's very well-made, and it's where the people are.

Where the people are would imply because of the social aspects.

------
zem
is it really valuable to keep the svn repository up for scripts that do
automatic updating? since nothing further will ever be pushed to it, those
scripts are now tracking an increasingly out-of-date repo.

the other point of view is that there are servers that the admin has had a
reasonable expectation of being able to set up and let run itself, but those
servers shouldn't be pulling from anyone's svn repo anyway.

~~~
yuvadam
Off the top of my head, here's one (somewhat) common use case that can break:

    
    
        pip install -e svn+http://code.djangoproject.com/svn/django/trunk#egg=django
    

It's definitely reasonable to keep the old repo up, for this case, and others.

~~~
zem
but that is now getting an old version of django. is that really what is
wanted?

~~~
StavrosK
If you're getting a specific version, sure.

------
richardlblair
I'm thrilled and excited to see this transition. I'm also very grateful for
all the work the Django team does. I really love the framework as a whole.

I hope the Django team can fully utilize the benefits of using github, and
further decrease the resistance to contributing (through pull requests).

With this change bugs like #17144 wouldn't haunt me for months on end, because
I'd just fix it.

~~~
richardlblair
Also, please don't end up like the mongodb github project. They have 70 pull
request, 0 closed.

------
wpietri
_cough_ retrospective _cough_

A postmortem is what you do when you try to understand the cause of death:
<http://en.wikipedia.org/wiki/Postmortem>

</nitpick>

~~~
eblume
Definitions notwithstanding, I tend to prefer the term 'AAR' (After Action
Report). I had a manager in an early campus IT job that had been in the
Marines, and he enforced a strict mandatory-AAR policy for anything even
remotely complex.

It's really a fantastic idea and something I fully intend to use in every
capacity that makes sense going forward. It doesn't make much sense as part of
the software design flow, but it absolutely could (and probably should) be a
tool in any deployment protocol.

My AARs usually read pretty much like this blog post, more or less to the T,
although we emphasized what we would do differently in the future more.

~~~
wpietri
Yeah, I think it's an excellent practice. I get the metaphorical use of
"postmortem", but think "after-action report" (for the document) and
"retrospective" (for the meeting) better capture the flavor of what a good one
looks like. And like you, I think the most valuable part is what to do
differently next time.

The way I work them into the software design flow is just to do them
regularly, with varying granularity. We do one every Friday afternoon with
beers for the last 30-60 minutes of the day.

Normally we discuss whatever interests us most about the week past. But a
couple of weeks ago one of the engineers suggested we do one covering the
whole year, and it was great. Lots of interesting observations.

