I got the raw markup of the untampered page:
http://code.djangoproject.com/wiki/WikiStart?version=250=txt
But when I tried to submit it, it was rejected as spam, though I have
set my email using settings.
Perhaps the triagers should also get a non-committing apache auth to
boost their no-spam
On 1/18/07, Michael Radziej <[EMAIL PROTECTED]> wrote:
Hi,
somehow the reopen button went on vacation with the trac udate--can
anyone call it back? It would be very appreciated by ticket #3320 ;-)
(At least, I cannot reopen from closed/invalid)
Michael, I see that ticket was closed as
On 1/18/07, Jeff Forcier <[EMAIL PROTECTED]> wrote:
...
Anyway, don't know if the current blank-ness is because someone wanted
to vandalize,
251 was vandal, 252 was removing the vandalism, but not restoring the original:
http://code.djangoproject.com/wiki/WikiStart?action=diff=251
On 1/18/07, telenieko <[EMAIL PROTECTED]> wrote:
...
On fields like USZipCode or USState and those which are **really** region
speciffic could be put on contrib (why would somebody outside US want those
fields? ie) we could end up with SpainRegion, CaribeanIsland... you get the
idea.
It seems
On 1/19/07, Michael Radziej <[EMAIL PROTECTED]> wrote:
Hi,
what's our policy about anonymously changing the review state or about
doing this for your own tickets? Do we want a peer review system such
that really somebody else should check the ticket, or is it alright if
you put it in the
On 1/19/07, Lawrence Oluyede <[EMAIL PROTECTED]> wrote:
How can I reopen this ticket?
http://code.djangoproject.com/ticket/3320
It's "ready for checkin" but "closed: invalid" also.
It was closed with reason but now it has been fixed
Jacob is working to get re-open available again.
On 1/21/07, Victor Ng <[EMAIL PROTECTED]> wrote:
>
> I ought to be able to start committing code in the next day or two.
> argh... i hate hard disks.
I kinda like 'em. I remember booting off floppies. Not much fun. :)
--~--~-~--~~~---~--~~
You received this
I suspect you have 2 different definitions of the signal under different
import paths. Ensure your python path doesn't have overlapping
directories, and that your signal imports refer to the same sys.modules key
(e.g. some_app.signals.foo all over, not proj.some_app.signals.foo and
I've had this scenario before - you have two interleaving units of work
(through composition of code from different sources or concerns). You want
progress recorded for one unit of work, but perhaps not the other. Without
django, you'd have two open connections. In my experience the simplest
You can use atomic just over the section that causes the error. The issue
is that different db engines have different semantics under error during
transaction. Rolling back to the last savepoint (as atomic does when
nested) recovers the ability to complete the remainder of the transaction.
With a
An alternative that might work well is to triage tickets to mentors, so
that a list of tickets with willing mentors is available. It would feel
less judge-y than "easy pickings" and also broaden the pool of tickets that
could be worked by a newcomer. Of course it hinges on a willing pool of
501 - 511 of 511 matches
Mail list logo
