Re: Djangopeople.net status
FWIW, Eldarion would be delighted to sponsor the hosting via Gondor at no cost to DSF (or anyone else). Thanks, Patrick Altman --- Patrick Altman Nashville, TN On Thursday, May 10, 2012 at 6:39 PM, Russell Keith-Magee wrote: > On Thu, May 10, 2012 at 8:55 PM, Bruno Renié (mailto:bubu...@gmail.com)> wrote: > > On Thu, May 10, 2012 at 8:04 AM, Russell Keith-Magee > > mailto:russ...@keith-magee.com)> wrote: > > > On Thu, May 10, 2012 at 9:19 AM, Aaron C. de Bruyn > > (mailto:aa...@heyaaron.com)> wrote: > > > > On Wed, May 9, 2012 at 1:37 PM, Alex Sosnovskiy > > > (mailto:alecs@gmail.com)> wrote: > > > > > > https://convore.com/djangopeoplenet-development/ - gives http404 > > > > > > > > > > > > > > > > > > > > Djangopeople.net (http://Djangopeople.net) is dead? > > > > > > > > > > If to be honest I don't understand you, guys! What's the profit of > > > > > rewriting > > > > > views to class-based if djangopeople.net (http://djangopeople.net) is > > > > > down for a year ? > > > > > > > > > > > > > > > That's because the rewritten code has never been deployed. > > > > > > Look at the whois record for djangoproject.com > > > > (http://djangoproject.com) verses > > > > djangopeople.net (http://djangopeople.net). I don't think > > > > djangopeople.net (http://djangopeople.net) is officially part > > > > of Django. > > > > > > > > > > > > I can confirm for you -- djangopeople.net (http://djangopeople.net) has > > > never been an "official" > > > part of the Django project. It was always an effort run outside of the > > > official (although Simon, the original developer, is a Django core > > > developer). > > > > > > That said, I'm still interested in making djangopeople.net > > > (http://djangopeople.net) an official > > > resource of the Django project. It was a very useful resource in it's > > > time, which I for one miss. If anyone is interested (including Bruno, > > > if he's still interested) in managing the project for the long term, > > > let me know. > > > > > > > > I am still interested, the issue right now is to get admin access to > > the djangopeople.net (http://djangopeople.net) DNS records and an > > up-to-date dump of the data. > > Regarding that, Simon Willison is pretty hard to reach and the best > > way to contact him is via Andew Godwin who can talk to him IRL. But as > > you may know, they're both busy people so that's why we're in the > > current situation. > > > > I'll shake the tree again and see what I can do. > > Another option would be to start from scratch; if we're making the > official, we could host you at people.djangoproject.com > (http://people.djangoproject.com), start with a > clean database, and use the blog/mailing list/etc to get the word out > and repopulate the database. It's less than ideal, but it would get > over the hurdle. After all, we're perfectionists with deadlines :-) > > > There is also the issue of hosting, at the time Andrew was happy to > > host the rebirth of djangopeople.net (http://djangopeople.net) on ep.io > > (http://ep.io) but since it's closing > > down we'd have to find another option. > > > > As Jacob noted, the DSF can help out here. If you can come up with an > estimate of what you need, I can put it to the board and get you those > resources. > > Yours, > Russ Magee %-) > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto:django-developers+unsubscr...@googlegroups.com). > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. -- 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 from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Inclusion of easy-thumbnails into Django Contrib
Another "community voice" contribution on this thread... I am of the opposite opinion. I think it would be better for Django as a whole if django.contrib approached zero. In fact, I would have no problem with seeing it go away completely and promote auth and sessions to core but done in a way that is pluggable. The reasoning behind this opinion is that it leaves the surface area in the project smaller to maintain and it's really not that hard to add a sorl-thumbnail external app to a Django project. Furthermore, it provides more freedom for these apps to mature and develop at their own pace. I realize I could very well be in a minority opinion here, but thought I'd throw it into the mix nonetheless. On Sep 16, 2010, at 11:33 AM, Brian O'Connor wrote: > I have absolutely no pull in decision making, but maybe my message will count > towards a "community voice". > > I think that including an image thumbnail package that integrates into the > database as easily as sorl.thumbnail and easy_thumbnail are is a great idea. > From what I can tell, sorl.thumbnail was the de facto standard for getting > thumbnails in to Django, and I think it has just as much of a place in Django > contrib as some of the other contrib apps do. I don't think it belongs in > the core, but contrib seems like an excellent place for it to go along with > the other batteries in the pack. > > On Thu, Sep 16, 2010 at 12:24 PM, Yo-Yo Ma wrote: > I have no data to support the following assertion, but it's not too > unreasonable: More people probably need thumbnail images than they > need comments. Comments are most used on blogs, whereas thumbnails can > be used on blogs, e-commerce, photo hosting, social networking, > project management, et al. It's not to say that we don't need > "contrib.comments", just that I wouldn't want to lose easy_thumbnails. > > > On Sep 15, 11:32 pm, "David P. Novakovic" > wrote: > > Actually, that really did sound negative. Sorry :) > > > > Is there a trac ticket open to address this issue? Generally it'd be > > better to get discussion happening over a ticket and if there are > > serious issues that need to be addressed then they can be discussed > > here. > > > > I know it'd be nice to get things like easy-thumbnails accepted into > > django.contrib , but the truth is that this probably falls outside of > > things that that should be in contrib. Contrib isn't really an easier > > way to get stuff into django, it still has to satisfy a bunch of > > conditions like the rest of the code in the core. > > > > The real question is not "can it be included?" but why is it a problem > > that this is a third party lib at the moment? Is there a strong case > > that it be better if it was part of django core or does it do its job > > just fine the way it is now? > > > > David > > > > On Thu, Sep 16, 2010 at 3:09 PM, David P. Novakovic > > > > wrote: > > > I don't want to sound negative, but answering your own question before > > > anyone else can doesn't change the answer ;) > > > > > D > > > > > On Thu, Sep 16, 2010 at 3:00 PM, Yo-Yo Ma > > > wrote: > > >> Is there any plans to > > >> incorporatehttp://github.com/SmileyChris/easy-thumbnails/ > > >> into django.contrib? I have seen so many apps/libraries come into and > > >> go out of existence (http://code.djangoproject.com/wiki/ThumbNailsfor > > >> instance mentions sorl-thumbnails which is no longer being developed). > > >> I just turned the key with easy-thumbnails and voila. It's like magic, > > >> but not. It's easy enough to see what's going on behind the scenes. > > > > >> This is something that, with the help of the core and other > > >> contributors, could be really great. It works for me as it it is, but > > >> it may not work for a more "enterprise" application that uses S3, etc. > > >> It might not be highly efficient (I wouldn't know). It might have bugs > > >> that I just haven't noticed yet. I'm mentioning all of this because I > > >> know somebody will say, "Why move it into Django if it's doing just > > >> fine as a separate project?". After experiencing the bliss I thought > > >> I'd drop a line here about it, and see what you guys thought. > > > > >> -- > > >> 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. > > >> To unsubscribe from this group, send email to > > >> django-developers+unsubscr...@googlegroups.com. > > >> For more options, visit this group > > >> athttp://groups.google.com/group/django-developers?hl=en. > > -- > 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. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-d
Re: #12991 Adding support for unittest2: request for review
On Sep 26, 2010, at 7:44 PM, Russell Keith-Magee wrote:
> On Mon, Sep 27, 2010 at 6:24 AM, Karen Tracey wrote:
>> I've run it on Python 2.4 & 2.5 (Ubuntu, sqlite DB) with no problems.
>>
>> I do have some feedback on the @skipIfDB addition: I'd really like if this
>> could be used to distinguish between the different MySQL storage backends.
>> From a very brief look it seems like currently there are a bunch of tests
>> skipped when the DB backend is MySQL, under the assumption that MySQL does
>> not have transaction support. However MySQL does have transaction support
>> when the InnoDB storage engine is used, so it would be nice if these tests
>> were only skipped when the MySQL/MyISAM combination were in use, not when
>> MySQL/InnoDB was used.
>>
>> Similarly there are a bunch of tests that fail or produce errors when the
>> MySQL/InnoDB combination is in use, because that combination does not
>> support forward foreign-key references when loading fixtures. It's not ideal
>> to skip a bunch of tests for function that really should be tested on this
>> combination (aggregates, for example), but for now at least the fixtures
>> used by these tests do not allow them to pass on MySQL/InnoDB, so they might
>> as well just be skipped. I have quit ever trying to run the full Django test
>> suite using MySQL/InnoDB because there are just too many "known failures"
>> there. It would be nice if the addition of @skipIfDB improved that. (For
>> that matter I also never run the full suite with MySQL/MyISAM because the
>> lack of transaction support with that combo makes it just too slow to run
>> the full suite, but I don't know of any way to improve that situation.)
>>
>> One difficulty in adding this extra check is that it is hard to know for
>> sure what storage engine is in use. If the database definition dict includes
>> 'OPTIONS': { "init_command": "SET storage_engine=" } then we know
>> the engine is in use. If not, the default configured engine for
>> the MySQL server will be used, and that could be either one. I'd be inclined
>> to say if you want to skip tests based on a particular storage engine being
>> used, then you need to make it explicit in the test settings what engine you
>> are using. So I'd be happy if this @skipIfDB threw an error if it was asked
>> to skip based on storage engine but could not find in the test settings what
>> storage engine was being used.
>
> The problem with this approach is that you can configure MySQL to use
> InnoDB by default for table creation, so there won't necessarily be
> any Django settings providing evidence that transactions are
> available.
>
>> Another difficulty is figuring out how to nicely specify this additional
>> requirement. Have not given that a whole lot of thought yet. Right now the
>> @skipIfDB takes a simple string (matched against DB ENGINE key) or iterable
>> of strings. Supporting querying both ENGINE and OPTIONS, and allowing for
>> more than one to be listed, might get a bit ugly. I am curious why the
>> iterable option here was added -- are there a lot of cases in the current
>> suite where tests need to be skipped on a set of DB backends and not just
>> one?
>
> The use case for the iterable is everywhere that PostgreSQL is the
> skip target, because we have 2 backends that need to be skipped.
>
> I'm in agreement that the ENGINE-string based skipIfDB isn't a
> particularly robust test. If nothing else, it means that if a user
> writes a third-party engine for MySQL (or anything else) in order to
> change some subtle behavior, the test suite won't be any use to them,
> because the string match won't cause the appropriate tests to be
> skipped.
>
> One thought here would be to introduce a variable on the backend
> itself that is a 'db identifier' - i.e., a string that clearly
> identifies the vendor, independent of the path that has been used to
> install the backend. So, for example, a check for
> connection.db_identifier = 'postgresql' would always tell you that
> you're dealing with PostgreSQL, regardless of the import path to the
> actual backend.
>
> This has three potential benefits.
>
> 1. We can avoid the need for the iterable skipIfDB version.
> 2. We enable writers of third-party backend for Django supported
> databases to benefit from test skip annotations
> 3. We provide a name that can be used for backend-specific features,
> such as the index-hinting proposal that has been floating around.
>
> However, this still doesn't address the InnoDB problem, or provide any
> support for completely external backends -- for example, the writers
> of the DB2 backend can't use Django's test suite, because the DB2
> backend isn't specifically named in Django's source code (nor should
> it).
>
> It also occurs to me that in most cases, the skip should actually be
> based on capabilities, not on the backend itself. We should be
> skipping because the backend doesn't support transactions, or because
> the backend doesn't allow forw
