Re: GitHub migration planning

2012-04-20 Thread Daniel Sokolowski
Thank you Alex and Max for your responses. -Original Message- From: Alex Ogier Sent: Friday, April 20, 2012 3:15 PM To: django-developers@googlegroups.com Subject: Re: GitHub migration planning On Fri, Apr 20, 2012 at 2:58 PM, Daniel Sokolowski wrote:

Re: GitHub migration planning

2012-04-20 Thread Alex Ogier
On Fri, Apr 20, 2012 at 2:58 PM, Daniel Sokolowski wrote: > Was BitBucket (mercurial system which is python based) not considered? And > could someone point me to a url where I can read the discussion on this > migration; I am rather curious why it’s happening –

Re: GitHub migration planning

2012-04-20 Thread Max Thayer
Paul, I meant no offense. I should have been more clear that I meant my question to explore what makes Trac ideal for Django. My apologies for any misunderstandings. Daniel: Indeed, BitBucket was considered. There's a thread about it from pretty recently here:

Re: GitHub migration planning

2012-04-20 Thread Daniel Sokolowski
Was BitBucket (mercurial system which is python based) not considered? And could someone point me to a url where I can read the discussion on this migration; I am rather curious why it’s happening – the current system works so I see no reason to fix it. From: Max Thayer Sent: Friday, April 20,

Re: GitHub migration planning

2012-04-20 Thread Paul McMillan
Max, and others on this thread, Arguing about the specific mechanics of how github issues work isn't productive. Put very plainly: Django will not move to github issues because they cannot support our open community triage process. This is not negotiable. Regards, -Paul -- You received this

Re: GitHub migration planning

2012-04-20 Thread Max Thayer
Luke, maybe I don't understand something about Trac, but some of the issues raised by you or those you quoted seem easily fixed. Consider: "- there isn't a notion of "component", so there's no way to ask "give me > the list of all contrib.auth tickets, so I can find the duplicate > quickly";"

Re: #18094: signals, model inheritance, and proxy models

2012-04-20 Thread Anssi Kääriäinen
On Apr 12, 10:27 pm, Anssi Kääriäinen wrote: > > So perhaps we do need the signal inheritance behavior to be opt-in when > > connecting the signal handler. I think I'd like to see a deprecation > > path so that eventually the inheritance behavior is the default, and you >

Re: Improved assignment_tag

2012-04-20 Thread Anssi Kääriäinen
On Apr 19, 6:21 pm, Choongmin Lee wrote: > Is it only me who needs a simple tag with optional assignment, e.g. that > both {% mytag %} and {% mytag as varname %} are possible? > > Attached is a patch that make the assignment optional for assignment_tag. > > If this change

Reverse manager assignments doing an implicit save

2012-04-20 Thread Anssi Kääriäinen
I was going through ORM tickets marked ready for checkin and stumbled upon ticket #14368. The ticket is about caching of o2o fields. The interesting part is not the caching, but this functionality: class A: pass class B: a = O2O(A, null=True, related_name='b') a1 = A.save() b1 = B.save()

Re: GSoC 2012: Security Enhancements

2012-04-20 Thread Rohan Jain
On 16:03 +0100 / 18 Apr, Luke Plant wrote: > On 15/04/12 05:23, Rohan Jain wrote: > > On 22:50 +0100 / 13 Apr, Luke Plant wrote: > >> The reason for the strict referer checking under HTTPS is set out here: > >> > >> https://code.djangoproject.com/wiki/CsrfProtection > >> > >> Particularly, it is

Re: GitHub migration planning

2012-04-20 Thread Luke Plant
On 18/04/12 22:44, philipn wrote: > Hey folks! > > I started a wiki page to help plan a migration to GitHub: > > https://code.djangoproject.com/wiki/GitHub%20Migration > > I don't know what I'm doing, but I do know that the current Trac setup > (attaching patches, etc) is less accessible to