ogier

#!/bin/sh

echo "Leaked my email?"

git log -n 1 --pretty=format:%ae

ogier

# Local settings (stuff that is unique per deployment). Checked into source control.
# To deploy, copy settings.template to settings.py and modify to taste.

from settings_common import *

DEBUG = True
TEMPLATE_DEBUG = DEBUG

DATABASES = {
    'default': {

ogier

Replacing auth.User with as little magic as possible

Here is my proposal for replacing auth.User in a sane, backwards-compatible, non-magical fashion.

1. Split off the current functionality of auth.User into reusable components. Proof of concept that this can be done transparently is available: https://github.com/ogier/django/blob/auth-mixins/django/contrib/auth/mixins.py . The changes there, with independent password, profile, groups/permissions and identity support being shipped as abstract models, are totally transparent to Django's test suite.
2. Ask users to reimplement a User model if they want to change anything. This, while arguably invasive, already has precedent in nearly every other batteries-included framework out there (See Ruby on Rails, ASP.NET MVC, Play, etc.). In addition, this has the advantage of making AUTH_PROFILE a dinosaur. Why implement a one-to-one model accessible indirectly via method on auth.User when you can just stick your fields where they belong.
3. Break any hard d

ogier

GSoC 2012: auth.User replacement

Alex Ogier
Rising Senior, Princeton University
[email protected]

Technical Details

The scope of this project is to break any hard ties to the auth.User model, and allow Django developers to cleanly specify alternate models to be used instead.

ogier

Here is a quick primer on how to update your branches to track the new django/django git repository. The commands that follow assume that you have your own fork of django/django-old, and that you have this cloned locally, as the origin remote.

Following these steps shouldn't break anything. So long as all your changes are committed and pushed to your fork of django-old already, nothing will affect them. If you are concerned, you can run them in a fresh clone of your fork.

Rebasing

First, add all of the new commits from the new Django repository.

$ git remote add django-new https://github.com/django/django

ogier

#Maintainer: Paolo Stivanin <admin AT polslinux DOT it>

pkgname=keepassx-git
pkgver=20120718
pkgrel=1
pkgdesc="The newest KeepassX v2!"
arch=('i686' 'x86_64')
license=('GPL')
depends=('qt')
makedepends=('git' 'intltool' 'cmake')