FYI I wrote a small userscript[1] (greasemonkey) that linkify ticket number
when browsing github.com/django/django. It's quite useful when reading the
source from the web interface since tickets referenced in python comments
are just a click away.
[1] https://gist.github.com/2528393
Le dimanch
On Sun, Jul 15, 2012 at 9:51 AM, Andy McCurdy wrote:
>
> On Jul 14, 2012, at 6:37 PM, Russell Keith-Magee wrote:
>
>>
>> My only concern is:
>>
>>> We could store which fields have these hooks upon ModelBase.__new__
>>> construction and so skip most fields and overhead in __init__.
>>
>> I'm not s
On Jul 14, 2012, at 6:37 PM, Russell Keith-Magee wrote:
>
> My only concern is:
>
>> We could store which fields have these hooks upon ModelBase.__new__
>> construction and so skip most fields and overhead in __init__.
>
> I'm not sure if I'm misreading your intentions here, but just to be
> s
Hi,
On Sunday, July 15, 2012 11:07:41 AM UTC+2, Anssi Kääriäinen wrote:
>
> I think we should categorically close pull requests which are non-
> trivial and do not contain ticket reference, and also those pull
> requests which are more than "last polish" away from merge. Even in
> the case of l
Hi Anssi,
That's pretty much the conclusion we reached when we discussed how to handle
PRs at DjangoCon Europe (at least, if memory serves). When you review a pull
request, you should either commit it or close it.
--
Aymeric.
On 15 juil. 2012, at 11:07, Anssi Kääriäinen wrote:
> I am going
I am going through pull requests which are somewhat related to ORM.
Some of the PRs are clearly not ready to be pulled in. I think the
idea is that pull requests should only be done for ready to be merged
patches, and if the patch isn't ready the pull request should be
closed. So, I am verifying i