Wouldn't enabling this by default cause a problem for any automated
deploys? Ours typically run the migrate command on every deploy, just
in case there are new migrations, and any command that returns a non-0
exit status is going to look like a deploy failure.
Having the behavior change with a ne
On Thu. 2013-08-29 at 06:15 PM EDT, "Daniele Procida" wrote:
> Would there be any objection if I used a keyword ("afraid_to_commit"
> or something) to mark tickets that I think would be suitable for
> first-time committers doing the "Don't be afraid to commit" tutorial
> to tackle?
My first reac
I like this - it solves something that's always bugged me.
One nice addition would be to specify explicitly what .id a particular
Choice should have. It would be useful in converting existing code that
might not have chosen to number its choices the same way this proposal
does by default. It looks
On Mon. 2011-10-10 at 06:05 PM EDT, Carl Meyer wrote:
> In the spirit of making Django behave better as a Python library (c.f.
> Glyph's keynote at djangocon.us), I'd like to finally tackle removing
> the sys.path hacks in django.core.management.setup_environ.
Yes! I can't wait. I cannot count
On Mon. 2011-03-28 at 03:07 AM EDT, Russell Keith-Magee
wrote:
> One
> possibility: have two 'bug' options -- "Bug" and "Release-blocking
> bug". Easy to filter on, relatively easy to understand, and easy to
> correct if it gets mistriaged.
Apache HTTP Server uses a Severity field, with values
