Re: When to close pull requests

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

Re: pre_init/post_init vs. performance

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

Re: pre_init/post_init vs. performance

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 >

Re: When to close pull requests

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

Re: When to close pull requests

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

When to close pull requests

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