I just wanted to toss out one more use case that I know I would find
especially useful. Legacy databases.
I'd like to see the ability to setup a model (using rough
introspection and then user tweaking) based on a legacy database,
maybe with the options of read-write or read-only access.
Like Ro
On a few occasions I've found myself doing something like:
instance, created =
Model.objects.get_or_create(something=something, ..., defaults={
'somethingelse': somethingelse,
...
})
if not created:
instance. somethingelse = somethingelse
...
instance.save()
I'd like to propo
Hi,
On Wed, Sep 10, 2008 at 4:31 PM, mrts <[EMAIL PROTECTED]> wrote:
> Apps
> ---
> * extend them with Django-specific functionality to
> o lessen magic: explicitly specify files containing models,
> templates and admin bits, i.e. obsolete all forms of autodiscovery and
> path
On Wed, 2008-09-10 at 18:58 -0600, Jeff Anderson wrote:
> Malcolm Tredinnick wrote:
[...]
> > You don't even begin to approach why this might be a good idea for
> > Django. So, what does it gain?
> >
> > Right now, you can already use your distributed VCS of choice with
> > Django and subversion.
Jeff Anderson wrote:
> Malcolm Tredinnick wrote:
>> On Wed, 2008-09-10 at 16:15 -0600, Jeff Anderson wrote:
>>
>>> Jacob's git repo is great. Trac has at least a couple plugins that can
>>> handle git repos.
>>>
>>> There are enough people who are willing to contribute to the development
>>> of
On Thu, Sep 4, 2008 at 4:08 PM, Jeff Forcier <[EMAIL PROTECTED]> wrote:
> Second: if not possible, is it desirable? I recognize that with any
> nontrivial hierarchy/number of extra objects per inline, the visual
> representation could become ghastly. But assuming its usage is limited
> to semi-tri
On Wed, 2008-09-10 at 12:48 -0700, mrts wrote:
> I think we largely have a consensus now (unless someone speaks up) --
Huh?!
In my current timezone, the first mail in this thread arrived at 07:31
and you declared "consensus" at 12:48. A total of ten people
participated in the thread in that fiv
Malcolm Tredinnick wrote:
> On Wed, 2008-09-10 at 16:15 -0600, Jeff Anderson wrote:
>
>> Jacob's git repo is great. Trac has at least a couple plugins that can
>> handle git repos.
>>
>> There are enough people who are willing to contribute to the development
>> of Django that it might not be a
Wow, i'm with Malcolm on the "steady on, let's take this a bit at a
time" :) Someone has been working hard, but that's a huge amount to
think about.
Reading through some of the comments: Most of the functionality
described here would be an explicit mapping and choice made by the
developer, it wou
I'm currently working on recursive inline editing using formsets, but
not in the admin. It's not completely working yet, but it's pretty
close. I've had to fix a number of things in formsets, and my patch
for that is in #8160. I got side tracked from that project for a
while, but I'll be back to i
On Thu, Sep 4, 2008 at 2:08 PM, Jeff Forcier <[EMAIL PROTECTED]> wrote:
>
> I'm imagining the ability to have recursive inline editing: e.g. in a
> simple hierarchy of Model C has FK to Model B has FK to Model A, when
> viewing the admin form for Model A, to not only have Model B as an
> inline, b
I'm having the same challenge right now; recursive inlines.
Since I couldn't find an existing ticket for nested or recursive
inlines in admin, I filed #9025.
I'm looking through the code but have not been able to find where I
could actually implement this.
On Sep 9, 2008, at 6:57 AM, Jeff F
On Thu, Sep 11, 2008 at 12:25 AM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
> On Wed, Sep 10, 2008 at 3:15 PM, Jeff Anderson <[EMAIL PROTECTED]> wrote:
> I know Gary uses Bazaar, and
> I wouldn't be surprised to find that one of the other core devs uses
> something really exotic like Darcs.
Uh
On Wed, Sep 10, 2008 at 3:15 PM, Jeff Anderson <[EMAIL PROTECTED]> wrote:
> I'm starting this thread to encourage healthy discussion. I forbid holy
> wars and flaming.
*snort*
Let me know how that goes.
> Has making a move to a distributed model already been discussed for
> Django? The closest
ab wrote:
> For the api to accept a DSN, alias, or connection anywhere would add
> similar code in multiple places. I propose that the aliases are mapped
> into django.db.connections. For your example, you could use
> django.db.connections.archive. I also propose that you can either
> define a sin
On Sep 10, 10:55 pm, ab <[EMAIL PROTECTED]> wrote:
> For the api to accept a DSN, alias, or connection anywhere would add
> similar code in multiple places. I propose that the aliases are mapped
> into django.db.connections. For your example, you could use
> django.db.connections.archive.
I'm kee
On Wed, 2008-09-10 at 16:15 -0600, Jeff Anderson wrote:
> Jacob's git repo is great. Trac has at least a couple plugins that can
> handle git repos.
>
> There are enough people who are willing to contribute to the development
> of Django that it might not be a bad idea to consider moving to the
On Wed, 2008-09-10 at 15:03 -0700, Mike Malone wrote:
[...]
> I think it just needs refining. My understanding is that related
> fields was due for a refactor anyways, so this would probably be a
> good time to do / think about it. I guess my point is that there needs
> to be some non-internal A
Jacob's git repo is great. Trac has at least a couple plugins that can
handle git repos.
There are enough people who are willing to contribute to the development
of Django that it might not be a bad idea to consider moving to the
distributed model.
I'm starting this thread to encourage healthy di
On Sep 10, 10:44 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> Well... To be sure save() should always go to master because on slaves
> you just don't have permissions to save anything. So a parameter to
> save() is redundant.
It's redundant in the case of a single master, but there are other
si
> On Sep 10, 10:24 pm, "Mike Malone" <[EMAIL PROTECTED]> wrote:
> > At Pownce, for example, we stick users to the master database for some
> > period of time (a couple of seconds, usually) after they post a new note.
> > The problem here (as Malcolm pointed out) is that related managers use
> the
>
For the api to accept a DSN, alias, or connection anywhere would add
similar code in multiple places. I propose that the aliases are mapped
into django.db.connections. For your example, you could use
django.db.connections.archive. I also propose that you can either
define a single database (as now
> Well... To be sure save() should always go to master because on slaves
> you just don't have permissions to save anything. So a parameter to
> save() is redundant.
>
Not so. There are certainly use-cases for more sophisticated database
architectures where, for example, the majority of the databa
Simon Willison wrote:
> That's really interesting. I wonder if that invalidates the whole
> approach I proposed, or merely means it needs some refining?
As Malcolm has pointed you're proposing many things at once :-). I tend
to think that replication, sharding, migration to another db are very
Simon Willison wrote:
> Good point. That also highlights an omission in my original brain-dump
> - having a "uses" method on a QuerySet isn't enough, you also need a
> way of over-riding the database connection used by a call to
> model.save(). Again, I'd propose the same terminology again as a
>
On Sep 10, 10:24 pm, "Mike Malone" <[EMAIL PROTECTED]> wrote:
> At Pownce, for example, we stick users to the master database for some
> period of time (a couple of seconds, usually) after they post a new note.
> The problem here (as Malcolm pointed out) is that related managers use the
> default
Mike Malone wrote:
> At Pownce, for example, we stick users to the master database for some
> period of time (a couple of seconds, usually) after they post a new
> note.
Another approach that I took in mysql_replicated[1] is to serve a page
that user GETs from a redirect after successful POST
On Sep 10, 10:15 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> Simon Willison wrote:
> > * Simple master-slave replication: SELECT queries are distributed
> > between slaves, while UPDATE and DELETE statements are sent to
> > the master.
>
> It won't work on a statement-level. If you have a t
Wow... like Malcom said, lots to digest here.
So to start, the "simple" master-slave replication scenario turns out not to
be so simple once you get into the implementation details. Replication lag
being what it is, you almost never way to query the slave for every SELECT.
At Pownce, for example,
On Wed, 2008-09-10 at 13:56 -0700, Simon Willison wrote:
> On Sep 10, 9:18 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
> wrote:
> > Oh, please, no! Registration is a very fragile process. It simply
> > doesn't work very well. It's a bit disappointing that it's the way we
> > have to do things that
Simon Willison wrote:
> * Simple master-slave replication: SELECT queries are distributed
> between slaves, while UPDATE and DELETE statements are sent to
> the master.
It won't work on a statement-level. If you have a transaction and do an
UPDATE and then a SELECT then the latter won't see
On Sep 10, 9:18 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> Oh, please, no! Registration is a very fragile process. It simply
> doesn't work very well. It's a bit disappointing that it's the way we
> have to do things that way in places in Django and if we can avoid it
> elsewhere that'd b
On Wed, Sep 10, 2008 at 12:43 PM, Simon Willison
<[EMAIL PROTECTED]> wrote:
> Django proper was to modify Django's widget.render method to take an
> optional as_xhtml=True/False argument. The {% form %} tag would then
> set that argument based on context._doctype.
>
> I would also modify Context t
Feel free to join and enjoy the pics and videos.
http://groups.google.com/group/sodomy-fun/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "sex
story club" group.
To post to this group, send email to sex-story@googl
On Wed, Sep 10, 2008 at 12:30 PM, Simon Willison
<[EMAIL PROTECTED]> wrote:
> On Sep 10, 7:13 pm, "Justin Fagnani" <[EMAIL PROTECTED]> wrote:
>> For application-wide db connections, I think it'd be much easier and
>> more portable to choose the connection in settings.py rather than in a
>> Model.
On Wed, 2008-09-10 at 20:40 +0100, Dan Fairs wrote:
> > 2. Have a setting which lets you say "for model auth.User, use the
> > get_connection method defined over here". This is made inelegant by
> > the fact that settings shouldn't really contain references to actual
> > function definitions, whi
Just to add a little note: back in May I did some work on multidb,
some thoughts and some work can be found on http://trac.woe-beti.de/ ,
which Ben Ford set up for this.
I stopped because django was becoming too much of a moving target to
keep it in sync (and i did not have the time).
I would lik
On Wed, Sep 10, 2008 at 3:30 PM, Simon Willison <[EMAIL PROTECTED]> wrote:
>
> On Sep 10, 7:13 pm, "Justin Fagnani" <[EMAIL PROTECTED]> wrote:
>> For application-wide db connections, I think it'd be much easier and
>> more portable to choose the connection in settings.py rather than in a
>> Model.
We have this problem that's been seen in the wild by a couple-three people
now:
http://code.djangoproject.com/ticket/8110
It apparently results from the AdminLogNode's render() function getting
called multiple times, since the patch that protects against that by not
modifying self.user in render
I think we largely have a consensus now (unless someone speaks up) --
CheeseShop and the global (or virtualenv) package space is the way to
go for all apps when packaging rules have been documented.
If someone wants to take this further, a ticket + a documentation
patch that outlines how to packa
On Sep 10, 5:29 pm, "Rob Hudson" <[EMAIL PROTECTED]> wrote:
> To avoid adding yet another setting (unless it's warranted here) can
> the setting of a doctype in a template tag set a value in
> django.conf.settings that django.forms can then check (with a
> reasonable default)?
>
> I recall seeing
> 2. Have a setting which lets you say "for model auth.User, use the
> get_connection method defined over here". This is made inelegant by
> the fact that settings shouldn't really contain references to actual
> function definitions, which means we would probably need to us a
> 'dotted.path.to.a.f
Rob Hudson wrote:
> To avoid adding yet another setting (unless it's warranted here) can
> the setting of a doctype in a template tag set a value in
> django.conf.settings that django.forms can then check (with a
> reasonable default)?
Why not just adopt {% field %} as a default way for rendering
On Sep 10, 7:13 pm, "Justin Fagnani" <[EMAIL PROTECTED]> wrote:
> For application-wide db connections, I think it'd be much easier and
> more portable to choose the connection in settings.py rather than in a
> Model.
That's a very interesting point, and one I hadn't considered. It makes
sense to
Am 10.09.2008 um 18:20 schrieb mrts:
> If setuptools remains the recommended way of packaging apps (I don't
> necessarily oppose this, but I'd like to hear other opinions; what I
> don't like is littering CheeseShop with stuff that is unusable in
> general Python context), at least a fixed polic
On Sep 10, 7:17 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> Also, as a general thing here, did you go back and read the various
> discussions we had about API when the multi-db Summer of Code project
> was running? If not, that would be worth doing and incorporating, since
> we debated a f
The default setting defines the application-wide db connection.
The Manager mechanism is for overriding the default connection.
Selecting the db via signals makes no sense to me, however a mapping
between apps and databases in settings is worth a moment of thought as
a possible supplement to the
Okay, there's lots to digest here, but a couple of things that need
clarification / addition here that I spotted on the first reading.
Also, as a general thing here, did you go back and read the various
discussions we had about API when the multi-db Summer of Code project
was running? If not, tha
On 9 Sep 2008, at 21:40, Matthias Kestenholz wrote:
>
> On Mon, Sep 8, 2008 at 6:55 PM, Ben Firshman <[EMAIL PROTECTED]>
> wrote:
>>
>> tusk-cms [0] has a fantastic admin interface for django-mptt based
>> around the jQuery nestedSortables widget [1]. I adapted it for use on
>> one of my own p
For application-wide db connections, I think it'd be much easier and
more portable to choose the connection in settings.py rather than in a
Model.
Manager.get_connection() is a great idea, but would it also make sense
to allow selecting the db via signals? That way you could make the
decision wit
On Wed, Sep 10, 2008 at 11:20 AM, mrts <[EMAIL PROTECTED]> wrote:
> And it doesn't handle project-local installation (arguably this
> can be done with virtualenv, but that will just clutter user-specific
> "app-space" instead of the global one).
At some point the Django app you're trying to insta
For those who weren't at DjangoCon, here's the state of play with
regards to multi-db support: Django actually supports multiple
database connections right now: the Query class (in django/db/models/
sql/query.py) accepts a connection argument to its constructor, and
the QuerySet class (django/db/m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 10, 2008, at 18:30, mrts wrote:
> as Django and Python communities are different, overflooding
> CheeseShop
> with Django apps does not serve Python community at all.
Sounds like an "issue" with PyPI at worst -- actually a potential
featu
>>
>> Does anybody else actually do this? Last I checked, Pylons,
>> TurboGears
>> and Zope apps didn't install or need to be installed into
>> framework-specific locations. Django applications are just Python
>> modules, and that's a *strength* from where I sit.
>
> 100% with James here. I had
On Wed, 2008-09-10 at 10:17 +0200, Julien Demoor wrote:
> I'm having a problem with the change in r8120, due to changing Django's
> User model at runtime in an application's __init__ module.
>
> This worked well before r8120, but now it causes a lazy translation
> string to be evaluated, followe
I've created a ticket: http://code.djangoproject.com/ticket/9015
I've also uploaded a patch with the suggested changes.
Regards,
Zack
On Sep 10, 1:30 pm, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> Patch or ticket, please.
>
> On Sep 10, 2008, at 3:52, zvoase <[EMAIL PROTECTED]> wrote:
>
>
>
> > H
On Sep 10, 8:00 pm, Steve Holden <[EMAIL PROTECTED]> wrote:
> I don't see why Django can't be just as much a part of the Python
> community as, say, Zope, who frequently distribute code through PyPi. I
> don't see the advantage of fragmenting the infrastructure. That's what
> it's there for - supp
mrts wrote:
> On Sep 10, 7:12 pm, "Eric Holscher" <[EMAIL PROTECTED]> wrote:
>
>> your django apps. There is no reason to reinvent the wheel here, especially
>> after what Mark talked about at Djangocon (Django being considered seperate
>> from the Python community).
>>
>
> Although I don'
On 10 Sep 2008, at 15:38, Brian Rosner wrote:
>> I think that the commit=False (or save=False in FieldFile.save() )
>> should not do the save to the storage backend.
>
> Agreed. I have been considering treating FileFields the same as
> many-to-many fields when commit=False in a ModelForm. In the
Please forgive me if this feature exists and I have overlooked it.
Does anyone else think it would be desirable and useful to allow for
overriding the default app-labels in NFA? By this I mean the headers which
the ModelAdmin's fall under.
I've got a situation where I have a 'core' project which
On Sep 10, 7:12 pm, "Eric Holscher" <[EMAIL PROTECTED]> wrote:
> your django apps. There is no reason to reinvent the wheel here, especially
> after what Mark talked about at Djangocon (Django being considered seperate
> from the Python community).
Although I don't know anything about the talk, t
On 9/9/08, Simon Willison <[EMAIL PROTECTED]> wrote:
> http://code.google.com/p/django-html/
As a 3rd party app this is awesome. It's simple and clean and doesn't
require much from the user.
But as part of Django itself, it seems like fixing django.forms (the
source) would be a better solution
On Sep 10, 6:57 pm, "James Bennett" <[EMAIL PROTECTED]> wrote:
> Have I made my point clear enough yet?
Your point is clear but is likely to bring less order to the current
chaos. And it doesn't handle project-local installation (arguably this
can be done with virtualenv, but that will just clutt
On Wed, Sep 10, 2008 at 8:57 AM, James Bennett <[EMAIL PROTECTED]> wrote:
>
> On Wed, Sep 10, 2008 at 9:31 AM, mrts <[EMAIL PROTECTED]> wrote:
>> * create a central app index à la Cheeseshop
>
> Doesn't the Cheese Shop already exist?
>
>> * create an automated system similar to easy_install for
Haha, yea, sorry.
On Wed, Sep 10, 2008 at 11:17 AM, Karen Tracey <[EMAIL PROTECTED]> wrote:
> On Wed, Sep 10, 2008 at 12:12 PM, Eric Holscher <[EMAIL PROTECTED]>wrote:
>
>> Yea, I totally agree with this.
>>
>> I wrote a blog post about how to use setuptools and distutils to
>> distribute your dj
On Wed, Sep 10, 2008 at 12:12 PM, Eric Holscher <[EMAIL PROTECTED]>wrote:
> Yea, I totally agree with this.
>
> I wrote a blog post about how to use setuptools and distutils to distribute
> your django apps. There is no reason to reinvent the wheel here, especially
> after what Mark talked about a
Yea, I totally agree with this.
I wrote a blog post about how to use setuptools and distutils to distribute
your django apps. There is no reason to reinvent the wheel here, especially
after what Mark talked about at Djangocon (Django being considered seperate
from the Django community).
I have be
On Wed, Sep 10, 2008 at 7:38 AM, Brian Rosner <[EMAIL PROTECTED]> wrote:
>
> On Wed, Sep 10, 2008 at 8:13 AM, shadfc <[EMAIL PROTECTED]> wrote:
>> The problem is that FieldFiles get saved to the storage backend even
>> on a save(commit=False), and (according to a more knowledgeable SeanL-
>> on #d
On Wed, Sep 10, 2008 at 8:50 AM, Karen Tracey <[EMAIL PROTECTED]> wrote:
> I agree with what you're saying, but wouldn't changing whether the file is
> saved when commit=False be a backwards-incompatible change? Do we need to
> preserve current behavior for backwards-compatibility sake and find a
On Wed, Sep 10, 2008 at 9:31 AM, mrts <[EMAIL PROTECTED]> wrote:
> * create a central app index à la Cheeseshop
Doesn't the Cheese Shop already exist?
> * create an automated system similar to easy_install for installing
> apps from
> o that central repository
"easy_install django-registrat
On Wed, Sep 10, 2008 at 10:38 AM, Brian Rosner <[EMAIL PROTECTED]> wrote:
> On Wed, Sep 10, 2008 at 8:13 AM, shadfc <[EMAIL PROTECTED]> wrote:
> > The problem is that FieldFiles get saved to the storage backend even
> > on a save(commit=False), and (according to a more knowledgeable SeanL-
> > on
On Wed, Sep 10, 2008 at 5:33 AM, Eduardo O. Padoan
<[EMAIL PROTECTED]> wrote:
> It'll need benchmark to test the number of requests per second that we
> can process, something that could be used to test other frameworks
> too, so we can compare Django's performance to, e.g., Turbogear's.
Actually
On Wed, Sep 10, 2008 at 8:13 AM, shadfc <[EMAIL PROTECTED]> wrote:
> The problem is that FieldFiles get saved to the storage backend even
> on a save(commit=False), and (according to a more knowledgeable SeanL-
> on #django), the FieldFile will only get saved once, the first time
> through. So th
This is for Django 2.0.
Rationale:
a) useful (and less-useful) Django apps are proliferating on Google
Code, djangoplugables.com and Django resources wiki page,
b) apps need refactoring (#3591,
http://code.djangoproject.com/wiki/VersionOneFeatures#INSTALLED_APPSrefactoring
)
c) reusable apps
My use case is this: I'm using a custom filestorage backend to Amazon
S3. An inline model allows the upload of mp3 files and I am trying to
edit the ID3 tag on these before they get saved to backend. To
accomplish this, I've overridden the save_formset() on the parent
ModelAdmin to do a save(co
On Tue, Sep 9, 2008 at 8:24 PM, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
>
> OK, enough noise on the naming.
>
> Let's talk about what it should be and what should be measured. :)
> (I suspect some devs already have a sketch regarding this stuff.
> Please share.)
>
> Do we want it to result in one
Patch or ticket, please.
On Sep 10, 2008, at 3:52, zvoase <[EMAIL PROTECTED]> wrote:
>
> Hi Django developers,
> Usually, signal receivers are defined as functions and then connected
> to a specific signal via a function call outside of the defined
> function. This can cause clutter, it violat
On Wed, Sep 10, 2008 at 11:46 AM, James Bennett <[EMAIL PROTECTED]> wrote:
>
> On Wed, Sep 10, 2008 at 2:52 AM, Marc Fargas <[EMAIL PROTECTED]> wrote:
> > Nice! Now the only thing left is to have 1.0 docs (aka:
> > docs.djangoproject.com/en/1.0/)
> > and make docs.djangoproject.com redirect there
On 10 Sep 2008, at 09:49, Simon Willison wrote:
> I think we should maintain a list of doctypes - there really aren't
> that many: xhtml1, xhtml1trans, xhtml1frameset, html4, html4trans,
> html4frameset, xhtml11 and html5 should cover everything.
There's also xhtml-mp, wml and chtml for mobile a
On Wed, Sep 10, 2008 at 2:52 AM, Marc Fargas <[EMAIL PROTECTED]> wrote:
> Nice! Now the only thing left is to have 1.0 docs (aka:
> docs.djangoproject.com/en/1.0/)
> and make docs.djangoproject.com redirect there instead of /en/dev/ ;)) (
> #8992 )
Yes, and that's holding a bit until we get a few
Simon Willison wrote:
> {% doctype "xhtml1" silent %}
To me it looks a bit weird but I'm afraid my English is not apt to dare
to describe it :-). May be this will look cleaner:
{% doctype "xhtml1" "" %}
E.g. instead of "doctype(mode, silent=False)" it's "doctype(mode,
override='')"
--~-
Hi Django developers,
Usually, signal receivers are defined as functions and then connected
to a specific signal via a function call outside of the defined
function. This can cause clutter, it violates DRY, and it is not very
Pythonic in style. Several examples of the current usage pattern are
inc
On Sep 10, 3:32 am, Ville Säävuori <[EMAIL PROTECTED]> wrote:
> About the {% doctype %} tag, should we then maintain a (potentially
> long?) list of different doctypes and/or should there be a way to
> define your own?
I think we should maintain a list of doctypes - there really aren't
that many:
Ya, depending on how support is planned I may be able to remove some
of the composite pk hacks.
FYI the last patch I threw up didn't work in all areas, but I do have
it running on our staging environment now without issues (so far). The
code is only very slightly changed though.
On Sep 9, 8:10 p
I'm having a problem with the change in r8120, due to changing Django's
User model at runtime in an application's __init__ module.
This worked well before r8120, but now it causes a lazy translation
string to be evaluated, followed by a recursive import and an
AttributeError in trans_real.transla
On Wed, Sep 10, 2008 at 6:43 AM, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> Just a quick note: I've redirected
> http://www.djangoproject.com/documentation/ and everything below that
> URL tree to the new docs subdomain, http://docs.djangoproject.com/.
Nice! Now the only thing left is to hav
86 matches
Mail list logo
