Django git guidelines

A heads up: I am working on Git and Github usage guidelines. There is a ticket https://code.djangoproject.com/ticket/18307, and I have a github branch with some initial work https://github.com/akaariai/django/tree/django_git_guidelines (or for changeset

Re: Django git guidelines

2012/5/18 Anssi Kääriäinen > A heads up: I am working on Git and Github usage guidelines. There is > a ticket https://code.djangoproject.com/ticket/18307, and I have a > github branch with some initial work > https://github.com/akaariai/django/tree/django_git_guidelines

Re: Possible session key creation regression in 1.4

On Wed, May 16, 2012 at 4:38 PM, Aymeric Augustin wrote: > 2012/5/16 Tom Evans : >> So, is the session key being available part of the API, or is relying >> on the session key existing incorrect? > > Hi Tom, > > Accessing the session

Re: Django Admin Revamp - Any updates?

I agree with Idan. We mainly did Grappelli because of the look & feel (and then added some functionality like autocompletes). However, it just doesn´t make sense to simply "beautify" the existing admin-interface. Rethinking the functionality, adding flexibility, being able to customize ...

Re: Django git guidelines

On May 18, 2012 4:43 AM, "Anssi Kääriäinen" wrote: > > A heads up: I am working on Git and Github usage guidelines. There is > a ticket https://code.djangoproject.com/ticket/18307, and I have a > github branch with some initial work

Re: Possible session key creation regression in 1.4

On Fri, May 18, 2012 at 10:51 AM, Tom Evans wrote: > On Wed, May 16, 2012 at 4:38 PM, Aymeric Augustin > wrote: >> 2012/5/16 Tom Evans : >>> So, is the session key being available part of the API, or is

Re: Django git guidelines

On May 18, 1:44 pm, Calvin Spealman wrote: > >  - When upstream has changed use git rebase instead of git pull > > A rebase workflow has always been problematic, in my experience. It will > cause previously published commits to be rewritten, changing their hashes, > and

Localflavor Test Case issues

Hey, I'm trying to add localflavor for Singapore, and am running into issues getting my test cases to pass. When manually validate my test cases by running the validators from the django-admin shell, they pass all my test cases. But when I run my test cases from the test runner, I get:

DJango 1.3 - BundleError while rendering

Hi, I'm new to Django and trying to get an existing application to work on my development machine. When running the project, I get the following error: TemplateSyntaxError at / Caught BundleError while rendering: 'styles/libs/jquery-ui-timepicker-addon.css' not found (using staticfiles

Re: Possible session key creation regression in 1.4

Le 18 mai 2012 à 11:51, Tom Evans a écrit : > On Wed, May 16, 2012 at 4:38 PM, Aymeric Augustin > wrote: >> 2012/5/16 Tom Evans : >>> So, is the session key being available part of the API, or is relying >>>

Re: DJango 1.3 - BundleError while rendering

Please ask questions about using Django on django-users. The topic of this list is the development of Django itself. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to

Re: Django git guidelines

On May 18, 11:43 am, Anssi Kääriäinen wrote: > A heads up: I am working on Git and Github usage guidelines. There is > a tickethttps://code.djangoproject.com/ticket/18307, and I have a > github branch with some initial >

Re: Possible session key creation regression in 1.4

On Fri, May 18, 2012 at 1:38 PM, Aymeric Augustin wrote: > Le 18 mai 2012 à 11:51, Tom Evans a écrit : > >> On Wed, May 16, 2012 at 4:38 PM, Aymeric Augustin >> wrote: >>> 2012/5/16 Tom Evans

Re: Django git guidelines

Hi Anssi, Thanks for working on git usage guidelines! I very much agree that a pull request should only be created when the contributor considers the branch finished and ready for review and merge (for instance, there should never be a pull request created without the necessary docs and tests).

Re: Django git guidelines

On Friday, May 18, 2012 at 11:04 AM, Carl Meyer wrote: > Hi Anssi, > > Thanks for working on git usage guidelines! I very much agree that a > pull request should only be created when the contributor considers the > branch finished and ready for review and merge (for instance, there > should

Re: Django-mssql with the dream of passing the test suite

Thanks for the heads up. I'm getting very close to having the test suite pass. After I accomplish that goal and establish a more solid reference point for django-mssql, I'll look in to the work you've done with adodbapi. Regards, Michael Manfre On Thursday, May 17, 2012 10:14:23 AM UTC-4,

Re: Django git guidelines

On May 18, 6:04 pm, Carl Meyer wrote: > All in all, I would be -1 on making rebase a required part of > contributing to Django. I would prefer to leave this choice up to the > contributor, and say something like: > > "If you want your own name on the final commit in master, feel

Re: Django git guidelines

On May 18, 6:08 pm, Donald Stufft wrote: > I personally prefer doing normal merges with --no-ff. While "clean up > whitespace" > commits are extraneous, they don't particularly hurt anything. If an incoming > pull > request is particularly messy it's easy enough to say

Re: Django git guidelines

On Friday, May 18, 2012 at 12:30 PM, Anssi Kääriäinen wrote: > On May 18, 6:08 pm, Donald Stufft (http://gmail.com)> wrote: > > I personally prefer doing normal merges with --no-ff. While "clean up > > whitespace" > > commits are extraneous, they don't particularly

Re: Django git guidelines

I am +1 on merge --squash. The reason is that there is tremendous value to having a mostly linear mainline development branch, especially for one so widely depended on as Django's. My feeling is that we should aim to have the official branches consist of only those commits that we would feel

Re: Django git guidelines

On Friday, May 18, 2012 at 1:40 PM, Alex Ogier wrote: > I am +1 on merge --squash. The reason is that there is tremendous > value to having a mostly linear mainline development branch, > especially for one so widely depended on as Django's. My feeling is > that we should aim to have the official

Re: Possible session key creation regression in 1.4

Le 18 mai 2012 à 16:29, Tom Evans a écrit : > That may be fine for open source code, it's not appropriate here. Tom, I'm sorry, I can't follow your logic here. Also, given my experience in the area of sessions, I don't believe I could translate your requirements

Re: Django git guidelines

On May 18, 8:40 pm, Alex Ogier wrote: > I am +1 on merge --squash. The reason is that there is tremendous > value to having a mostly linear mainline development branch, > especially for one so widely depended on as Django's. My feeling is > that we should aim to have the

Re: Django git guidelines

On May 18, 8:43 pm, Donald Stufft wrote: > In my experience, squash makes git bisect harder, instead finding the bad > commit to be a small, atomic change, you're often given a large change where > you must then determine which change out of the entire commit caused the

Re: Djangopeople.net status

yeah. I got a few contacts through it, so it looks like it's positioned well and working, and I don't know if bringing .net back makes any sense. Most profiles will be redundant, won't they? Unless .net provides something more. We'd probably need a better djangogigs-alike. On Friday, May 11,

Re: Django git guidelines

On May 18, 2012, at 12:19 PM, Anssi Kääriäinen wrote: > I do not want us to have single commit per pull request. Instead I > would like to see nice clean logical commits. These make bisecting as > easy as possible. So, we mostly agree here. My feeling is that we want every commit in the main tree

Re: Django git guidelines

On Fri, May 18, 2012 at 7:38 AM, Anssi Kääriäinen wrote: > On May 18, 1:44 pm, Calvin Spealman wrote: >> >  - When upstream has changed use git rebase instead of git pull >> >> A rebase workflow has always been problematic, in my experience. It will

Re: Django git guidelines

On May 18, 10:29 pm, Calvin Spealman wrote: > > The idea is that when working on a topic branch, use git rebase. The > > published branches (django/django/master, django/django/stable/1.4.x) > > will never get rewritten history (except for truly exceptional > > situations).