g with good
faith efforts to view debug logging on an issue on a production Django
deployment. I feel the PR author's pain and hope their idea gets serious
consideration. My hope is that others here do as well.
Kind Regards,
Rob
--
You received this message because you are subscribed to the G
team.
In actuality, if you are doing things right, the biggest security issues
are exploits on the client side (viruses, phishing, key-loggers) and
incursions into your infrastructure.
Rob.
On Saturday, January 14, 2017 at 1:24:24 PM UTC-5, Chris Priest wrote:
>
> The way django'
om.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/0f8dbd9f-b42d-4d17-806b-d965c0999b85%40goo
On Wednesday, December 17, 2014 8:39:21 AM UTC-5, Daniele Procida wrote:
>
>
> We'd hate you to be "that guy" too. However, so far you are "that guy",
> since merely announcing that you have identified numerous accessibility
> issues is useless.
>
Ok. Tell the designer to google "chrome acce
On Tuesday, December 16, 2014 5:58:00 PM UTC-5, Christian Schmitt wrote:
>
> Somehow I hate it. The website is the worst website I've seen since a long
> time.
> The contrast is really aweful.
> The issue Tracker got unusable due to the colors that aren't focused on
> readability.
>
Clearly. My
LTS release is announced. Does anyone have any recommendations?
Thanks in advance for any guidance you can provide!
-Rob
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group a
This is a fascinating attack. I scanned all of the information that I
could find and it wasn't clear how this could be used to breach CSRF
protection. Is there more detail somewhere on that specific attack vector?
-Rob
On Tuesday, August 6, 2013 10:42:01 AM UTC-4, Jacob Kaplan-Moss
I opened bug: http://code.djangoproject.com/ticket/15043
I actually stumbled on this just a few days ago while trying to put a
session_key to user ID mapping into Redis upon login and was stumped
for awhile why it didn't match the session key of my logged in user.
-Rob
On Sun, Jan 9, 2011
plete widgets were in a
state of flux or had some warts. Our (Jannis and my) idea at the time
was to write our own from scratch, custom and optimized for Django.
That looks to be about a year ago so the state of things is probably
much different today. (Or not?)
-Rob
On Wed, Jun 2, 2010 at 7:
7;t these e-mails end up on other servers that might save the
message in a Unix mailbox format? And if so, wouldn't removing the
">" from the "From" cause problems?
-Rob
--
You received this message because you are subscribed to the Google Groups
"Django deve
dmin widgets. But perhaps
this could be worked on -- something like jQuery UI's widget factory
methods?
-Rob
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
7;s working well.
Happy to help in some way on this if I can.
-Rob
On Thu, Feb 18, 2010 at 2:20 AM, Ales Zoulek wrote:
> Hello,
> there a ticket about jQuery in admin that breaks any site-included jQueries
> and there's no easy/clean way to prevent it.
> http://code.djangoproj
abase.
Ticket 10587 was closed as a duplicate of 2626, but I think 10587 has
the better description and proposal in it.
-Rob
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@go
ors and also
reduces code change as you adapt your models.
All that said, I'm not sure if I'd propose this change for this
purpose... or if we did the method might better live somewhere else.
The model_to_dict method is used specifically for Forms as the
docstring cites: Returns a dic
a merge-queue branch is testing and verifying that
multiple patches play well together before actually hitting trunk.
For multiple big branches this is even more important.
-Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Googl
ite on its own. Something along the lines of
http://strawpollnow.com/ but not necessarily with the Twitter
integration?
Thanks,
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers&quo
sion process and the fact that the conference
took everyone's comments (which were private) into consideration when
picking the subset of talks. But I can imagine that's not for
everyone.
Thanks,
Rob
--~--~-~--~~~---~--~~
You received this message because yo
ions, reviewers to
give feedback, editors to clean up text and bring uniformity to the
whole thing, developers to make sure the software the tutorial is
describing is coded using best practices and works, a handful of
people to drive the process and foster
#x27;t seen this kind of behavior
before but it makes total sense. I think it's the way everyone does
it anyway, it would just take the manual command line changes out of
the process. I wonder what you would call such an option. ./bin/test
--smartfail?
Rob
--~--~-~--~~---
On Oct 2, 5:10 am, Harro wrote:
> Sounds like a bad plan, what if by fixing the failed test you break
> another one?
My philosophy on testing is that no one will do it unless it's blazing
fast, easy to use, and doesn't punish you.
My goal where I work was to make testing so simple that the othe
I'd really love to see a Selenium or Windmill integration into the
Django testing framework. That would be really fun to demonstrate in
class too when you get done. :D This idea was listed on
http://code.djangoproject.com/wiki/SummerOfCode2009.
--~--~-~--~~~---~--~---
wo other tickets that are slotted for
1.2 though:
http://code.djangoproject.com/ticket/4501 (via Nose's coverage
support)
http://code.djangoproject.com/ticket/11613 (you can use --pdb and --
pdb-failures to get a similar behavior)
Rob
--~--~-~--~~~---~--~~
You received t
I'll see if I can talk Jeff into adding what he's got as a start to
this. It looks solid to me.
Ticket and patches forthcoming...
On Sep 29, 2:47 pm, Simon Willison wrote:
> On Sep 29, 7:34 pm, Rob Madole wrote:
>
> > TEST_RUNNER = 'django.contrib.test.nose.run_
http://blog.jeffbalogh.org/post/57653515/nose-test-runner-for-django
It's certainly been done and doesn't require changes to Django.
On Sep 29, 1:34 pm, Rob Madole wrote:
> Ok, --failfast would be nice too :D, I think I remember seeing a
> ticket on that. So make that 4 fe
I think
it'd doable.
Eh?
Rob
On Sep 29, 1:23 pm, Rob Madole wrote:
> Yep, I use the pdb stuff too. That would be handy.
>
> The way this works in nose is through the testid plugin. Typically you
> do this:
>
> nosetests --with-id --failed
>
> This will create a file c
o the docs).
On one hand, I can see this argument: If you are adding 3 features
from nose, why not just use nose. But setting up nose and Django to
use it as the test runner isn't trivial the last time I checked.
We're using buildout to ease the pain.
Thanks for the input.
Rob
On Se
I've been using nose for our tests, and one of the features that I
really like is the ability to run the tests again but filter only the
ones that caused a problem.
I'm thinking it would look something like this
./manage.py test --failed
Does this sound worthwhile to any
w those empty tables. This one is going to be a hard sale on
our dev team. I'm anticipating the argument I'm going to have with
the DBA'ish fella on the team.
Rob
On Sep 14, 2:57 pm, Alex Gaynor wrote:
> On Mon, Sep 14, 2009 at 1:54 PM, Joseph Kocherhans
>
>
>
>
s
> were rejected.
>
> [1] http://code.djangoproject.com/wiki/CsrfProtection
I don't mind trying to piece a Wiki page together documenting the
current conversation. I agree it will make a good pointer for
reference and future discussions.
-Rob
--~--~-~--~~~---~--~--
ion really sucks - that's 9 new template tags polluting our
> default template namespace which do almost nothing. That said, if we
> added template tag namespacing we could at least do {% tag.br %}, {%
> tag.hr %} etc.
>
> They're all pretty horrible, but I think out of thos
hing
> I can contribute.
If we can come up with something that everyone is happy with, I'm in
for volunteering time to help code it. I'm sure it will be a learning
experience for me as far as Django internals, but I'm willing to put
the effort into it.
Thanks,
Rob
--~--~-
use of pieces of Django outside of Django as they
would all now rely on Django's templates.
There's also the option of something like Werkzeug's HTMLBuilder[2]
and their use in Solace widgets[3].
I don't claim to have the answer, but I'm willing to put time and
effort i
has done, but
perhaps something that's already being used in the Django community,
is open source, and could be improved a bit. Something like
DjangoSnippets perhaps?
-Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google G
Take a look at ticket 3011:
http://code.djangoproject.com/ticket/3011
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
the UI match that of the Django admin (overall theme, colors,
etc)?
* If the debug toolbar is incorporated, should we consider different
integration options? e.g. Currently the debug toolbar injects URLs
into the project in a rather ugly way -- could this be done better if
it were par
addition
> of DDT to django.contrib, you're going to need to make sense of the
> mess for the core team. The first step in this process is wrangling
> the forked community into a single repository that is a candidate for
> inclusion.
Hopefully I answered some of these questions and
ady had an idea on these wanted to add some more
details of what to cover under one of those topics, I (and others?)
can try to flesh one out during the 1.2 phase.
-Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Group
millions of rows for IP addresses.
Rather than simply consider how to delete those IPs, take a close look
at your database architecture as a whole. You're looking at db scaling
issues across the board. I'm not saying you can eliminate those
millions of ro
ite was a quick and simple
solution to concurrency and db locking issues. So making it explicit
wouldn't hurt, for the sole reason that it communicates that concept
(assuming of course it is documented :)
Since sqlite takes advantage of the DATABASE_OPTIONS field for
timeout, it w
runserver I think.
But it does have the added benefit of running a single command in a
single console.
./manage.py runserver --maildebugger
Other ideas or thoughts?
Thanks,
Rob
References:
[1] http://code.djangoproject.com/ticket/8638
[2] http://rob.cogit8.org/blog/200
Hiya,
I thought I would shout out ticket #1848 (30 minute increments in the
admin time widget) for inclusion in 1.1, if anyone wants it. I'm still
using it and others might find it useful.
http://code.djangoproject.com/ticket/1848
-rob
--~--~-~--~~~---~--~
ough backwards compat is
emphasized from 1.0 on I think there would be some leeway with a
fairly specific test feature. The worst situation would be buggy test
code, so if it turns out to be very complicated to maintain backwards
compat, we should leave it behind.
-rob
--~--~-~--~~-
ngs.py from the
project_template it would get laid down in your project when you ran
django-admin.py startproject, which is, I think, the appropriate place
for this relative path stuff to land.
See:
http://code.djangoproject.com/browser/django/trunk/django/conf/project_template/settings.py
+1 fro
n't think this would be confusing
(after all, this isn't python).
(Also, if you want to avoid confusion don't use a keyword that is
located within another language's looping construct :)
-rob
--~--~-~--~~~---~--~~
You received this message because
On 10/28/08, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> On Mon, Oct 20, 2008 at 12:33 PM, Rob Hudson <[EMAIL PROTECTED]> wrote:
> > I think decoupling messages from contrib.auth is a worthy step to
> > making auth a little bit more reusable.
>
> Agreed
On Oct 27, 11:21 am, oggie rob <[EMAIL PROTECTED]> wrote:
> Its a bit deeper than that... but I'm waiting for my friend to respond
> (he worked on sqlite issues at my last company). Hopefully I'll hear
> from him today and be able to add some more details.
Okay, so I go
> I agree, and this explanation looks good. +1
Its a bit deeper than that... but I'm waiting for my friend to respond
(he worked on sqlite issues at my last company). Hopefully I'll hear
from him today and be able to add some more de
On Mon, Oct 20, 2008 at 11:33 AM, Rob Hudson <[EMAIL PROTECTED]> wrote:
> * Should a pre-existing reusable app (like django-notification[2])
> be used/considered instead?
> [2] http://code.google.com/p/django-notification/
I actually meant to link to the django-notices app
" app, they make sense.
[1]
http://groups.google.com/group/django-users/browse_thread/thread/cf8f7aefe2039873
[2] http://code.google.com/p/django-notification/
Thanks,
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Goo
ee that it attempts to send even
with an empty ADMINS list. It should return if not self.to and not
self.bcc, I think.
> That would be pretty hilarious. Not particularly straightforward or
> maintainable though.
Yes, the got_request_exception signal seems like a better solution as
it giv
Did you try subclassing list (& overriding __iter__) for the ADMINS
object?
-rob
On Oct 15, 1:58 pm, Jesse Young <[EMAIL PROTECTED]> wrote:
> The built-in behavior for
> django.core.handlers.base.handle_uncaught_exception calls mail_admins
> for each internal server erro
Hi Devs,
At DjangoCon it was mentioned that you were working on a process for
nominating or approving 3rd party Django apps to be pulled in as
official contrib apps. I'm curious if that's been worked out yet.
Thanks,
Rob
--~--~-~--~~~---~--~~
You rec
and a reference in the ticket (and will wait instead of trying
to fix it now).
-rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to djang
like a pretty
handy feature so I think it should be reinstated.)
There is a ticket open on this: http://code.djangoproject.com/ticket/8377
-rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developer
f adding
an extra constructor parameter to existing forms, and ignored without
it.
-rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-dev
On Sep 23, 3:26 am, Simon Willison <[EMAIL PROTECTED]> wrote:
> On Sep 23, 9:00 am, oggie rob <[EMAIL PROTECTED]> wrote:
>> Is it worth a gut check to make sure this is worthwhile?
>
> Here's a useful case in point: the admin. Django's admin should ship
>
of flaming people & such - for the (lets be realistic)
very rare cases when a CSRF attack occurs. All you need is a template,
right? (And I would consider sending an email to the admin notifying
them that at attack was attempted, at least to get an idea of how
common these issues are.)
As far as how this fits into django, my suspicion is that you've got
multiple django installations going. However, if you can narrow down
the cause (and it comes from just one django installation), it is
probably worth logging a ticket.
-rob
--~--~-~--~~~---~--~
and updates (at the
time) django.newforms with some if/else logic based on the setting to
the various widgets' render methods. I can't seem to find it now.
I'm just trying to point out that for Django to output a string that
then later gets "fixed" sme
that I created the doctype part in a patch on this ticket
but didn't have the genius idea of the {% field %} tag to take it the
rest of the way...
http://code.djangoproject.com/ticket/7281
So awesome and simple. I love it.
I'll get rid of my weird form hack on my latest project and test
I see there is now a link to the registration page when you go to file a
ticket, but why not put it on page where the login/settings links are
(just underneath the search box). This is where it is by default in Trac
and people might expect to see it there, like I did myself initially.
signature.a
I've had the error before and found it difficult to find the link where
to register for an account. I had to ask in the IRC and someone had to
point me to it, I believe this could be made easier to find.
Go to code.djangoproject.com look at the tabs:
Login | Settings
Wiki, Timeline, Browse Sourc
OSCON is July 21st to the 25th in Portland, OR. It's not in a date
range listed but I'm curious if something could be arranged there? If
not a sprint maybe a BOF or just a meet and greet?
On Jun 25, 3:58 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> Hi folks --
>
> I'm setting up sprints
ted and the foreseeable future isn't too distant. :)
-Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googleg
On 6/19/08, Rob Hudson <[EMAIL PROTECTED]> wrote:
> Use the `-T`, `-t`, `-b` flags, or `-s` if the project has a "standard
> layout". This should bring over branches and tags as well.
I forgot to reference the man page (which was in my clipboard):
http://www.kernel.or
w the correct incantation to add other git-svn-created
> branches, feel free to school me :)
>
>
> Jacob
Use the `-T`, `-t`, `-b` flags, or `-s` if the project has a "standard
layout". This should bring over branches and tags as well.
-Rob
--
"ROCK OUT!" \m/.
were
easier, but there are some hackish ways to get it to work as is, so
maybe it's not worth the effort of distracting devs when a 1.0 push is
on.
-Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
&quo
probably want to do things slightly
differently with the results). However, I do think it would be
appreciated.
-rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to th
.com/group/django-developers/browse_frm/thread/5f3694b8a19fb9a1
Is this important for anyone else besides me?
My humble apologies,
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" gr
like the flurry of code
coming into the Linux kernel after an official release). It sounds
like a faster iteration process to me than people not wanting to break
trunk b/c it's the norm to run production websites off of it.
I'm not arguing for the above releases or a pre 1.0 relea
On 6/7/08, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> On Sat, Jun 7, 2008 at 7:23 PM, Rob Hudson <[EMAIL PROTECTED]> wrote:
> > Where I work we use 0.96 (though I use trunk on my personal projects).
> > We use 0.96 because we have up to 12 separate Django projects
sort of library would be a nightmare. Not even
mentioning having to support various Django releases on our production
servers. So we're stuck on 0.96 until 1.0 comes along.
Not so much a tough call to pick 0.96 in our case, but I'm jealous at
the
ith the change but it does change the way I think
about trapping errors with Django models somewhat -- being more aware
that assignment could raise and error rather than save().
-Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google G
e svn up'd trunk). I have some
data migration scripts that make a lot of assignments up front, extra
logic to clean up a few things, and then wraps the save() in a try
block.
-Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the
.
+1 from me, and it provides for a little motivation since there is a
target date on the horizon.
-Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, s
a patch release for any security updates.
Someone else could "own" the 0.98 release. Once 0.97 is no longer
supported, that frees me up to "own" another release.
Just a thought.
-Rob
--~--~-~--~~~---~--~~
You received this message because
, by
default, prefers the imperfect XHTML in newforms and the admin (and
other places)? If not a complete switch, could we at least not make
those who are anal about outputting HTML4 not have to work[1]
harder[2] than[3] those who are ok XHTML?
-Rob
[1] http://www.djangosnippets.o
database by default (e.g. Widget.objects.all() might always use an
OTHER_DATABASE while all other models use the main db, if you create a
custom Manager for Widget)
This still leaves questions about how syncdb would be achieved, at
least. But if it could be done, the API seems simple to understa
e set up a Google
code project with the hopes of this being included in Django once it's
working and all the kinks are worked out?
-Rob
On May 21, 2:30 am, Aral Balkan <[EMAIL PROTECTED]> wrote:
> Just a quick bump: has there been any progress on
erride the default formfield, supply it with an initial value, that
> should work.
>
> On Fri, May 9, 2008 at 3:14 AM, Rob van der Linde <[EMAIL PROTECTED]> wrote:
> > Hi, I have some code that I wish to move over to the newforms admin
> > branch. So far I have been able t
Hi, I have some code that I wish to move over to the newforms admin
branch. So far I have been able to convert my models no problem to the
new syntax.
One of my models has a many to many field to the Sites model that comes
with Django. The field is a required field, and prior to moving to the
newf
ofile information specific to our apps?
Thanks,
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe
x27;m purposefully looking
for it and can't find it.
Thanks,
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@google
E.g. use "[-\w]+" for slugs, use "\d+" for
digits or id numbers, etc.
Adrian makes a good point about not wanting multiple ways to specify
URLs. That does seem a bit ugly.
Thanks for the discussion. :)
-Rob
--~--~-~--~~~---~--~~
You receive
"{{" delimiter b/c it's already used in templates.
I'd think any delimiter could be used so long as it isn't hard to
distinguish it from typical regex syntax. (e.g. "[slug]" might not be
the best).
If interested, I could toy
engine=INNODB" }
Or to avoid this setting and to set MySQL to always use InnoDB, make
sure the "skip-innodb" setting is commented out in /etc/my.cnf and add
default-table-type=innodb (plus the other innodb_* settings you might
need). I've heard setting that DATABASE_OPTION adds
On 3/24/08, James Bennett <[EMAIL PROTECTED]> wrote:
>
> On Mon, Mar 24, 2008 at 3:23 PM, Ben Firshman <[EMAIL PROTECTED]> wrote:
> > Would proposing a complete replacement be a tad too controversial for a
> GSoC
> > project?
>
>
> Yes. It also wouldn't succeed as a project, because it's the
d also
promotes good url bundling.
--
kthnxbye,
-Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To uns
roblem that the other thread is trying to solve? eg:
"ellington.search" and "marketplace.search" would both map to
/media/search/.
-Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Dja
How do we go about setting up a new mailing list on google groups?
Anyone have a suggestion for a name?
Cheers!
-Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to
things have always been shelved for the 1.0 release.
-Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To u
On 12/11/07, Patryk Zawadzki <[EMAIL PROTECTED]> wrote:
> If you parse it with a true XML parser then the content gets unescaped
> on delivery. Then feed it to Python's BeautifulSoup to do anything
> else.
I'm using ElementTree to parse the RSS and you're right about the
unescaping. Thanks!
--~
On 12/11/07, Patryk Zawadzki <[EMAIL PROTECTED]> wrote:
> Why not use
> http://code.djangoproject.com/timeline?ticket=on&max=50&daysback=90&format=rss
> ?
I am actually. But I did just realize the description fields has the
full details of the comment. The description field would require a
bit
My goal is to focus
on changesets that have a larger impact on the code base, or dev list
threads that have a larger impact, etc. I'm sure that will always be
a challenge.
Thanks,
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed
to organize a group of newsletter editors?
A mailing list? If so, let's kick it off. Sounds like fun.
-Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to th
> Thanks for the speedy responses. I'll keep quiet now :)
Except to say that the mark_safe function works in view (as well as in
filters). Sorry I missed that, it solves my concerns nicely.
-rob
--~--~-~--~~~---~--~~
You received this message because
describe which fields are okay and
which aren't.
Thanks for the speedy responses. I'll keep quiet now :)
-rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to t
> I dunno about you, but I get data from places other than forms.
Well then, who makes decisions about trust for that data?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this g
for bringing this up again, but I didn't find any discussion on
this approach in any of the older threads and I'm only now updating my
templates. And of course, if it HAS been discussed, please point me to
the thread and we won't rehash this.
-rob
--~--~-~--~~--
l can do
rotations and it's not such a burden on one person each week.
Thanks,
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-d
1 - 100 of 302 matches
Mail list logo
