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:
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 –
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:
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,
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
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";"
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
>
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
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()
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
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
11 matches
Mail list logo