Re: One Django instance, hundreds of websites

[Jari Pennanen]

On Jan 31, 8:30 am, James Hancock  wrote:
> This post is getting pretty long. But I had a simple Django fix that would
> make it work a lot easier for me, and might help others. (I say this because
> of how I implemented it, I am working with about 60 different sites and it
> is a pretty simple arrangement)
>
> Imagine you were able to set a site_id per request rather than relying on
> the settings SITE_ID. Django would then checked for a request's site_id *first
> *and then *second *check the settings one.

Thats in my proposal implementation "2. Using middleware"
http://ciantic.github.com/multisited/README.html

What comes to documenting which settings can be changed runtime, it
sounds madness. Is there any settings like that? I can't think of any,
all of the relevant settings will suffer threading issues as soon as
changed in middleware (unless used local thread trick, and that is not
advised). There is no reason one should change settings attributes on
runtime unless in tests.

-- 
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: Question on ForeignKey (on_delete=DO_NOTHING)

[Rahul]

Carl,
 you are right. I didn't mention the actual problem i was facing...
Prior to 1.3 the way we implemented 'sqlflush' was to simply turn on
'cascade_delete' in DB2 and then return 'delete  from TABLENAME' for
every table passed in. Without the delete_cascade, this required the
delete's to be sorted in right order (and then what about circular
references). But in 1.3 with the new DO_Nothing this wouldn't work.
And i was seeing many errors in 1.3 due to PKEY/FKey issues that i
thought were related to follow-on test cases expecting some rows to be
there, but no more there (since delete & cascade happened). Knowing
this as 1 issue, i just wanted to skip it and run the remainder of
tests to get a feeling how many other things i need to deal with for
1.3...

BTW i have come up with a different workaround for sqlflush and it
works, but i still see lots of errors related to pkey/fkey
dependencies out of sync :-(. Digging into that and if i am stuck will
post some queries again

thanks
Rahul Priyadarshi

On Jan 25, 9:15 am, Carl Meyer  wrote:
> On Jan 24, 3:51 am,Rahul wrote:
>
> > Can you let me know how i can specify that this test case should not
> > be run, when i run the inbuilt unit test-cases. Currently i just run
> > them like this 'python runtests.py --setting=settings'
>
> You should not avoid running test_do_nothing. It is written such that
> it can pass without error on backends that support referential
> integrity, and the comment mentions a possible IntegrityError as a
> reason for how it is written, but nowhere in the test is an
> expectation of IntegrityError tested. In other words, the test should
> (and does) pass equally well on backends that do or do not support
> referential integrity, and it should pass for  your backend as well.
>
> The only place in the deletion tests where IntegrityError is
> explicitly tested for is in test_protect, as the PROTECT
> IntegrityError is raised by Django's own deletion code, not the
> backend.
>
> Carl

-- 
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: RFC: Add a "needinfo" state to triaging

[Daniel Moisset]

On Wed, Nov 17, 2010 at 10:49 AM, Russell Keith-Magee
 wrote:
> On Wed, Nov 17, 2010 at 9:22 PM, Gabriel Hurley  wrote:
>> Bear in mind that this is a *very* old Trac installation... ;-)
>
> Hopefully not for long.
>
> Jacob is in the process of bringing a new server online to host
> djangoproject.com, and part of that upgrade will be an updated Trac
> install, running Trac 0.12 rather than 0.10. Once that upgrade is in
> place, it will (hopefully) be a lot easier to implement this and other
> Trac changes.
>

Hi. This message intends to be a small nudge to reactivate
http://code.djangoproject.com/ticket/14702 which was waiting on the
trac migration.

I know this probably must be handled by a trac admin, but if I can
help in some way, I have enough experience setting up trac to help
here. Just let me know. I also can help updating
http://code.djangoproject.com/wiki/ContributingHowTo (which will be
needed for the #14401 doc update) once this change is done

Regards,
   D.

-- 
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.

Using OneToOneField in reverse from values or values_list is rejected with "Invalid field name"

[Matt Hoskins]

Working on some code I've hit that the reverse name for a
OneToOneField cannot be used, it seems, in values_list or values. I
couldn't see why there would need to be such an exclusion, given it is
a one-to-one relationship, so am wondering if it's just an oversight
in the code or a deliberate exclusion?

The portion of code that is rejecting doing e.g.
"values_list('onetoonereversename')" is in setup_joins where the if
line reads:

if not allow_many and (m2m or not direct):

The values of "m2m" and "direct" come from opts.get_field_by_name and
it seems that the reverse of a OneToOne gives the same results as the
reverse of a ForeignKey, as of course both are not m2m and are not
direct. Looking at the code later on in setup_joins it describes the
path where direct is false and m2m is false as being "One-to-many
field (ForeignKey defined on the target model)", so it looks like the
logic I've quoted above of "if not allow_many and (m2m or not direct)"
has the "not direct" clause in to reject reverse ForeignKey
relationships and in doing so also rejects reverse OneToOne
relationships (and with the latter case I suspect it need not!).

If someone a bit more knowledgeable about the query machinery could
comment on whether it does look like an oversight or is a deliberate
exclusion, then if it's the former I'll log it as a bug.

Assuming the rest of the code is ok in the case of a reverse OneToOne
then something along the lines of "if not allow_many and (m2m or (not
direct and not isinstance(getattr(field,'field',None),OneToOneField))"
instead could work to allow OneToOne reverses through in setup_joins
when allow_many is False.

Regards,
Matt

-- 
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.

settings.py should have way to hide key/values even when debug set True

[Matteius]

I think it would be really useful to have a way (possibly a decorator
such as @hide_setting) such as to protect deployed sites when they
switch over to debug mode.  To me this would be a most useful setting
to have, especially when protecting secret key settings.  Please be
advised.

-- 
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: settings.py should have way to hide key/values even when debug set True

[Horst Gutmann]

On Mon, Jan 31, 2011 at 5:02 PM, Matteius  wrote:
> I think it would be really useful to have a way (possibly a decorator
> such as @hide_setting) such as to protect deployed sites when they
> switch over to debug mode.  To me this would be a most useful setting
> to have, especially when protecting secret key settings.  Please be
> advised.
>

If I remember correctly, settings starting with SECRET_ are not shown
on the debug page.

-- Horst

-- 
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: ANN: Server upgrade on djangoproject.com

[Renato Garcia Pedigoni]

I don't know if it's related to this server upgrade, but I can't install
django from svn with pip anymore [1]. However, it's still working with
easy_install.

[1] I'm using: pip install http://code.djangoproject.com/svn/django/trunk

Pip error log on http://dpaste.com/371850/

Thanks

--
Atenciosamente,
Renato Garcia Pedigoni


On Sun, Jan 30, 2011 at 11:15 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

> On Sun, Jan 30, 2011 at 2:11 PM, Russell Keith-Magee
>  wrote:
> > On Sat, Jan 29, 2011 at 5:45 AM, Jacob Kaplan-Moss 
> wrote:
> >> On Fri, Jan 28, 2011 at 3:33 PM, Jacob Kaplan-Moss 
> wrote:
> >>> I'm starting the switchover to the new djangoproject.com server right
> >>> now. Might be around 5 mins of downtime or so.
> >>
> >> Migration should be complete now. I'm still cleaning up a few
> >> last-minute things, but if you notice anything wrong please pop into
> >> #django-dev on freenode and let me know.
> >
> > You're not around in IRC (I'm guessing you're in bed) so here's a
> > couple of issues:
>
> One more -- it looks like SVN checkin triggers aren't working. I've
> just checked in a couple of tickets, and they weren't autoclosed by
> the commits.
>
> Russ %-)
>
> --
> 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.
>
>

-- 
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: ANN: Server upgrade on djangoproject.com

[Chuck Harmston]

Since you're installing directly from SVN, you'll need to preface the URL with 
"svn+". Just 20 minutes ago I successfully did a pip install using the 
following command:


pip install svn+http://code.djangoproject.com/svn/django/trunk/#egg=django


Chuck

On Monday, January 31, 2011 at 12:57 PM, Renato Garcia Pedigoni wrote:

> I don't know if it's related to this server upgrade, but I can't install 
> django from svn with pip anymore [1]. However, it's still working with 
> easy_install.
> 
> 
> [1] I'm using: pip install http://code.djangoproject.com/svn/django/trunk
> 
> 
> Pip error log on http://dpaste.com/371850/
> 
> 
> Thanks
> 
> 
> --
> Atenciosamente,
> Renato Garcia Pedigoni
> 
> 
> On Sun, Jan 30, 2011 at 11:15 AM, Russell Keith-Magee 
>  wrote:
> 
> > On Sun, Jan 30, 2011 at 2:11 PM, Russell Keith-Magee
> >  wrote:
> > > On Sat, Jan 29, 2011 at 5:45 AM, Jacob Kaplan-Moss  
> > > wrote:
> > >> On Fri, Jan 28, 2011 at 3:33 PM, Jacob Kaplan-Moss  
> > >> wrote:
> > >>> I'm starting the switchover to the new djangoproject.com server right
> > >>> now. Might be around 5 mins of downtime or so.
> > >>
> > >> Migration should be complete now. I'm still cleaning up a few
> > >> last-minute things, but if you notice anything wrong please pop into
> > >> #django-dev on freenode and let me know.
> > >
> > > You're not around in IRC (I'm guessing you're in bed) so here's a
> > > couple of issues:
> > 
> > 
> > One more -- it looks like SVN checkin triggers aren't working. I've
> >  just checked in a couple of tickets, and they weren't autoclosed by
> >  the commits.
> > 
> >  Russ %-)
> > 
> >  --
> >  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.
> > 
> > 
> > 
> > 
> > 
> 
> 
> 
> 
>  -- 
>  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.
> 
> 
> 




-- 
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: One Django instance, hundreds of websites

[Carl Meyer]

On Jan 31, 1:49 am, Xavier Ordoquy  wrote:
> The thread is pretty long because there are also 2 threads in one:
>  - one for simply changing the site_id per request
>  - one for changing the all setting per request

Exactly!

For the record, as far as I'm concerned #15089 is limited in scope to
the first issue: making contrib.sites provide API for getting a Site
object that projects can configure such that the returned Site object
is based on the request, without having to resort to threadlocals.
This may not satisfy everyone's definition of "true multitenancy," but
it covers a lot more use cases than contrib.sites does now.

For those whose definition of "true multitenancy" requires being able
to modify arbitrary settings at runtime per-request, I see only two
realistic (thread-safe) options:

1) Using threadlocals, as discussed above.
2) Fixing Django's settings to be an instance of some kind of
configured "app" object (a la Flask, except we can't call it an app
because we already use that name for something different) rather than
a process global. I don't know that anyone disagrees this would be
better in principle, but I haven't seen any proposals yet for how to
do it in a backwards-compatible way (though I'm not sure that means
it's impossible). If it can't be done backwards-compatibly, that puts
it in the Django 2.0 timeframe (i.e. in the foggy mists of some
unknown future time).

Carl

-- 
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.

Discussion about language discovery - ticket 15168

[zay2]

You see things from your point of view, so lets give it one more shot:

1) Browsers/Op? systems are not available in many small languages and
therefore the speakers of languages like estonians have to use
browsers/systems in english and their browsers are therefore in
english - they may not desire it.

2) Those users do not know how to change their browsers language - you
got to know that you and are are HUGE minority - perhaps only 5% of
users know that they CAN change their browser language. Even less
people know how and want to change it.

3) those 95% of people who dont know that they CAN change their
browser language or know how to, usually visit pages, which are in
their own language (the language that they speak every day, not the
language their browser is set to).

4) I want to make pages that can be seen in default language - the
language that the target audience of the page uses.

Now im not saying - "i want to ignore this 1 language when it is not
set in a cookie"(quoting bpeschier). Im saying that i want the page be
in language used by target audience. I cant do this with this accept
headers based language discovery

"In your case I would extend the LocaleMiddleware? to mirror that;
check the HTTP_ACCEPT_LANGUAGE in META before handing it to the
LocaleMiddleware?-superclass and rewrite English to Estonian "(quoting
bpeschier) - There already is default language setting - it just does
not work in all (probably most) cases.

"Without the detection, I would get your site in Estonian, which is
probably jibberish to me."(quoting lrekucki). Well in such cases - You
are not the target audience. If you were, then the default language
would be English or Polish.

Ask your parents or grandparents, if they know what browser accept
headers or if they can change those. This probably is irrelevant if
they come from english speaking (or other countries which's languages
are spoken by millions and millions of people) countries, since they
never need to do anything like this anyway. Parents & grandparents in
countries like Estonia, Latvia, Lithuania and so on, dont know about
the accept headers or such either. But in most cases, their browsers
are in english and they dont even know that this could be a problem.

Now we are making the websites for our customers and our customers are
supposed to know their target audience. If we cant deliver the website
which its target audience can see in its default language then
something is wrong. I fixed this wrong by commenting out undesired
code. Not very DRY. getting everybody, who face similar problem,
extending their middleware is also not very DRY. Why would all those
people have to repeat themselves? I still say that such setting option
would be best way to solve this.

If i cant change your mind about this - so be it. If im gonna be the
only one to see sanity in this, then so be it - i know how to fix
this. Just thought, that this would be nice minor improvement.

-- 
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: Discussion about language discovery - ticket 15168

[Sergiy Kuzmenko]

What you are proposing is too idiosyncratic to be part of the Django
framework. As already suggested by others it should be trivial enough
to create your own middleware to address your needs:

if language preference not specified explicitly by the user:
   set it to the language of your choice

Put this middleware before Django's standard locale middleware and
live happily ever after.

Cheers
Sergiy

On Mon, Jan 31, 2011 at 1:21 PM, zay2  wrote:
> You see things from your point of view, so lets give it one more shot:
>
> 1) Browsers/Op? systems are not available in many small languages and
> therefore the speakers of languages like estonians have to use
> browsers/systems in english and their browsers are therefore in
> english - they may not desire it.
>
> 2) Those users do not know how to change their browsers language - you
> got to know that you and are are HUGE minority - perhaps only 5% of
> users know that they CAN change their browser language. Even less
> people know how and want to change it.
>
> 3) those 95% of people who dont know that they CAN change their
> browser language or know how to, usually visit pages, which are in
> their own language (the language that they speak every day, not the
> language their browser is set to).
>
> 4) I want to make pages that can be seen in default language - the
> language that the target audience of the page uses.
>
> Now im not saying - "i want to ignore this 1 language when it is not
> set in a cookie"(quoting bpeschier). Im saying that i want the page be
> in language used by target audience. I cant do this with this accept
> headers based language discovery
>
> "In your case I would extend the LocaleMiddleware? to mirror that;
> check the HTTP_ACCEPT_LANGUAGE in META before handing it to the
> LocaleMiddleware?-superclass and rewrite English to Estonian "(quoting
> bpeschier) - There already is default language setting - it just does
> not work in all (probably most) cases.
>
> "Without the detection, I would get your site in Estonian, which is
> probably jibberish to me."(quoting lrekucki). Well in such cases - You
> are not the target audience. If you were, then the default language
> would be English or Polish.
>
> Ask your parents or grandparents, if they know what browser accept
> headers or if they can change those. This probably is irrelevant if
> they come from english speaking (or other countries which's languages
> are spoken by millions and millions of people) countries, since they
> never need to do anything like this anyway. Parents & grandparents in
> countries like Estonia, Latvia, Lithuania and so on, dont know about
> the accept headers or such either. But in most cases, their browsers
> are in english and they dont even know that this could be a problem.
>
> Now we are making the websites for our customers and our customers are
> supposed to know their target audience. If we cant deliver the website
> which its target audience can see in its default language then
> something is wrong. I fixed this wrong by commenting out undesired
> code. Not very DRY. getting everybody, who face similar problem,
> extending their middleware is also not very DRY. Why would all those
> people have to repeat themselves? I still say that such setting option
> would be best way to solve this.
>
> If i cant change your mind about this - so be it. If im gonna be the
> only one to see sanity in this, then so be it - i know how to fix
> this. Just thought, that this would be nice minor improvement.
>
> --
> 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.
>
>

-- 
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: One Django instance, hundreds of websites

[Jari Pennanen]

On Jan 31, 8:27 pm, Carl Meyer  wrote:
> On Jan 31, 1:49 am, Xavier Ordoquy  wrote:
>
> > The thread is pretty long because there are also 2 threads in one:
> >  - one for simply changing the site_id per request
> >  - one for changing the all setting per request
>
> Exactly!

I've not supported arbitrary settings, only SITE_ID, MEDIA_URL and
MEDIA_ROOT. These alone should allow to do sites like Weebly etc.

In fact I directly oppose multinenacy for e.g. INSTALLED_APPS -- it
can be solved later, even these three settings will take a huge effort
to get support.

> 1) Using threadlocals, as discussed above.

Yes, thread locals are great hack for SITE_ID, MEDIA_URL and
MEDIA_ROOT meanwhile, other settings I have not studied.

-- 
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: Various small issues

[Klaas van Schelven]

Hi all,

Maybe I wasn't clear enough last time... I've provided patches for
both these old problems and would appreciate either a brutal Linus
style rant for being such an idiot or would like to see the patches
applied. Silence... not so much.

ciao,
Klaas

On Jan 14, 6:28 pm, Klaas van Schelven 
wrote:
> Hi all,
>
> I've been looking into a few old unresolved issues.
>
> http://code.djangoproject.com/ticket/11667
> "Full traceback if import error before model validation" is a simple
> annoyance. On the issue page (one year old) various solutions are
> suggested, each with a patch. Can someone take a decision on the best
> patch and move this forward?
>
> http://code.djangoproject.com/ticket/10967
> save(force_update=True) crashes with model inheritance
> Turned out to be quite simple. I've provided tests & a patch. If
> someone who knows about the ORM is willing to take a look I guess we
> could move to a check in quickly.
>
> If anyone would care to take a look, that would be much appreciated,
>
> Klaas

-- 
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: Various small issues

[Stephen Kelly]

Klaas van Schelven wrote:

> Hi all,
> 
> Maybe I wasn't clear enough last time... I've provided patches for
> both these old problems and would appreciate either a brutal Linus
> style rant for being such an idiot or would like to see the patches
> applied. Silence... not so much.
> 

Hi Klass,

Your post is understandable but unfortunately timed. I am in the same boat 
as you in that I would like my issues attended to.

However, a feature of the django development process, as far as I can tell, 
is that once a future django version has had blockers assigned and tickets 
marked with that milestone, nothing else is likely to get attention unless 
it sparks someones particular interest, even tickets which are 'done', 
'obvious' or 'trivial'.

Another feature of the django development process is that issues with 
tickets don't get forgotten. The best we can do is wait a week after the 1.3 
release and then re-post if you think they're still overlooked.

All the best,

Steve.


-- 
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: settings.py should have way to hide key/values even when debug set True

[Russell Keith-Magee]

On Tue, Feb 1, 2011 at 12:12 AM, Horst Gutmann  wrote:
> On Mon, Jan 31, 2011 at 5:02 PM, Matteius  wrote:
>> I think it would be really useful to have a way (possibly a decorator
>> such as @hide_setting) such as to protect deployed sites when they
>> switch over to debug mode.  To me this would be a most useful setting
>> to have, especially when protecting secret key settings.  Please be
>> advised.
>>
>
> If I remember correctly, settings starting with SECRET_ are not shown
> on the debug page.

Not completely correct. There is a list of settings that won't be
displayed -- anything that contains the text
SECRET, PASSWORD, PROFANITIES_LIST,  or SIGNATURE will be replaced
with asterisks. It's not an unreasonable suggestion that this list
should be user-configurable.

As for the original proposal - I'm not sure how a decorator would help
here. What is the decorator being applied to? What would the decorator
indicate? How would that information be exposed to the debug view?

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.
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: Various small issues

[Russell Keith-Magee]

On Tue, Feb 1, 2011 at 7:47 AM, Stephen Kelly  wrote:
> Klaas van Schelven wrote:
>
>> Hi all,
>>
>> Maybe I wasn't clear enough last time... I've provided patches for
>> both these old problems and would appreciate either a brutal Linus
>> style rant for being such an idiot or would like to see the patches
>> applied. Silence... not so much.
>>
>
> Hi Klass,
>
> Your post is understandable but unfortunately timed. I am in the same boat
> as you in that I would like my issues attended to.
>
> However, a feature of the django development process, as far as I can tell,
> is that once a future django version has had blockers assigned and tickets
> marked with that milestone, nothing else is likely to get attention unless
> it sparks someones particular interest, even tickets which are 'done',
> 'obvious' or 'trivial'.

This is true of blockers, but not of milestone tickets. Milestones are
helpful suggestions for what to look at next. Especially at this late
stage in the process, we only pay close attention to the blockers.

We have limited resources. We have a deadline for a 1.3 release that
has sailed by quite nicely. It's not like we're sitting around waiting
for work to do. I'm sorry that I haven't personally had time to look
at these tickets -- but in that respect, your tickets are in the same
boat as about 500 others.

That means we have to prioritize.

About a month ago, we identified about a dozen tickets that were
problems that were so bad that we couldn't release 1.3 without
addressing them. These tickets were either serious regressions, caused
data loss, or were flaws in newly added features. Those tickets get
the highest priority for attention.

Next on the list is the list of RFC tickets. Ideally, we want to make
sure that there are no RFC bugfix tickets when we release 1.3, because
this represents work where at least two sets of eyes have looked at a
ticket.

Next, there are issues that the core team have experienced in their
day to day travels. If a committer experiences a bug and needs it
fixed for their own projects, it will probably get fixed.
Alternatively, if someone is in IRC at the right time and place and
can stir the interest of a committer (possibly by engaging the
committer in some quid pro quo), then the ticket may jump the queue.

Unfortunately, at the bottom of the list is everything else.

> Another feature of the django development process is that issues with
> tickets don't get forgotten. The best we can do is wait a week after the 1.3
> release and then re-post if you think they're still overlooked.

This is true, but misses an important intermediate step.

The core team aren't the only people who can review tickets. In fact,
all you need is for someone who isn't you to review your ticket and
say that it looks good (by Django's standards -- which means
documentation, tests, PEP8 etc). Once you've reviewed a ticket and
you're happy, you can promote it to RFC -- which puts it much closer
to being committed.

So... Stephen, meet Klaas. Klaas, meet Stephen. You both have tickets
than need review. Why don't you review each others tickets? That way
you both end up with tickets in RFC.

Remember -- this is a community project. There is a core team with the
commit bit, but we really do rely on the rest of the community to help
us organize those tickets.

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.
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: settings.py should have way to hide key/values even when debug set True

[Cal Leeming [Simplicity Media Ltd]]

Second.

On Tue, Feb 1, 2011 at 1:00 AM, Russell Keith-Magee  wrote:

> On Tue, Feb 1, 2011 at 12:12 AM, Horst Gutmann 
> wrote:
> > On Mon, Jan 31, 2011 at 5:02 PM, Matteius  wrote:
> >> I think it would be really useful to have a way (possibly a decorator
> >> such as @hide_setting) such as to protect deployed sites when they
> >> switch over to debug mode.  To me this would be a most useful setting
> >> to have, especially when protecting secret key settings.  Please be
> >> advised.
> >>
> >
> > If I remember correctly, settings starting with SECRET_ are not shown
> > on the debug page.
>
> Not completely correct. There is a list of settings that won't be
> displayed -- anything that contains the text
> SECRET, PASSWORD, PROFANITIES_LIST,  or SIGNATURE will be replaced
> with asterisks. It's not an unreasonable suggestion that this list
> should be user-configurable.
>
> As for the original proposal - I'm not sure how a decorator would help
> here. What is the decorator being applied to? What would the decorator
> indicate? How would that information be exposed to the debug view?
>
> 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.
> 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.
>
>

-- 
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.

Pluggable models

[David Greisen]

Dear List,

This is my first time writing to the list. I've been working with Django for
the last two years and recently started hacking on Django itself.

For a while I have felt restricted by the fact that I cannot replace the
user model. I use the profile feature for additional methods and attributes.
However, it is inelegant, particularly when I wish to modify an existing
user method. Also, as I develop a library of applications, and try to use
apps I find on the web, I find it difficult to reuse apps because they
expect certain models to be imported from certain places. For example, two
years ago I created an app that integrated with the US postal service web
APIs. I recently was working on a crm-type website that I would like to add
shipping functionality to. However, the shipping app had its own
Package model that needed to tightly integrate with a ShippingEvent model.
My crm already has its own Letter model that tightly integrates with the
UserProfile model and the reports views. I have no easy way to integrate
these two applications. The only way I can see is to completely fork my USPS
app and integrate its functionality line-by-line with my crm.

I think this problem could be solved by making models pluggable. I realize
that this has been proposed before (
http://groups.google.com/group/django-developers/browse_thread/thread/2dd8fb9ea1fd3763/ef7db33f2fe713a3).
I have been thinking about how to bring the advantages of a pluggable
architecture to django's models without any of the disadvantages described
in the thread.

It would need to:
1) be completely backwards compatible
2) not require additional unpythonic behavior (such as interfaces)
3) Existing models should be pluggable with no modification
4) Not require any significant change in code base

I think I may have a system that meets these requirements. All it would
require of the developer is to place a dictionary of components in her
project's settings.py file. Each key would be the dotted path to an original
model, each value would be the dotted path to the model that will replace
the original model. When the original model is imported, the replacement
model would instead be returned completely transparently to the application
importing the model.

With this system in place, I could simply move all the functionality in my
package model in my USPS app to a base class, then my letter model in my crm
could inherit from that base model. I set my
settings.COMPONENTS={'usps.models.package':'crm.models.letter'} and
magically, my USPS app and letter app work together. Every time my USPS app
gets a usps.models.package it actually receives a crm.models.letter that
does the same thing. My ShippingEvents is now

This system definitely meets the first three requirements.

1) it is completely backwards compatible. If there is no COMPONENTS
dictionary, everything works exactly the way it did before plugging was
added.
2) there is no need for interfaces or getter functions that get the
appropriate class or object, you simply import and call as usual.
3) existing models can be overridden with no extra work.

4) is the only part I cannot answer fully. I started an implementation, just
to see if it was even possible,  and I've made some progress - it works with
quite a few of my test models. However, I am just learning the internals of
Django, and there are still errors with my implementation. I wanted to put
this to the list before going further.
As far as I've gotten with actual implementation: When a project imports the
original model (original.model), django.db.models.base.ModelBase.__new__
checks to see if "original.model." is in the COMPONENTS dictionary. If it
is, it gets the path to the replacement model ("replacement.model2"), and
gets the replacement class. It calls
django.db.models.register_models('original', model=) which
registers the replacement model class under the original application and
with the name 'model'. Now, there are multiple copies of replacement.model2
in django.db.models.loading.cache, so django.db.models.get_models() removes
duplicates before returning all models. There are other internals that will
need to be modified, besides these three methods, in order to eliminate the
occasional errors I'm getting in syncdb; I'm still figuring out what those
are.

Your feedback is appreciated.

David Greisen

-- 
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: Various small issues

[Brian Neal]

On Jan 31, 7:35 pm, Russell Keith-Magee 
wrote:
>
> The core team aren't the only people who can review tickets. In fact,
> all you need is for someone who isn't you to review your ticket and
> say that it looks good (by Django's standards -- which means
> documentation, tests, PEP8 etc). Once you've reviewed a ticket and
> you're happy, you can promote it to RFC -- which puts it much closer
> to being committed.

Russ, the advice you gave above doesn't quite jive with what is here:
http://docs.djangoproject.com/en/dev/internals/contributing/#triage-by-the-general-community

"Please don’t promote tickets to “Ready for checkin” unless they are
trivial changes – for example, spelling mistakes or broken links in
documentation."

I held off on marking something RFC because of that. Can you please
clarify? Thanks.

BN

-- 
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: Pluggable models

[Russell Keith-Magee]

On Tue, Feb 1, 2011 at 9:22 AM, David Greisen  wrote:
> Dear List,
>
> This is my first time writing to the list. I've been working with Django for
> the last two years and recently started hacking on Django itself.
>
> For a while I have felt restricted by the fact that I cannot replace the
> user model.

You're not the first person with this complaint.

> I think this problem could be solved by making models pluggable. I realize
> that this has been proposed before
> (http://groups.google.com/group/django-developers/browse_thread/thread/2dd8fb9ea1fd3763/ef7db33f2fe713a3).

The idea of pluggable models has been proposed before. The thread you
reference isn't the most recent incarnation of that discussion,
either:

http://groups.google.com/group/django-developers/browse_thread/thread/c8e2397fefd85030
http://groups.google.com/group/django-developers/browse_thread/thread/c8921795bc7868af

The app-refactor that is referenced in those discussions was Arthur
Koziel's GSoC project last year; merging the results of this project
into trunk is one of the big ticket items that has a lot of support
for the 1.4 timeframe.

> I have been thinking about how to bring the advantages of a pluggable
> architecture to django's models without any of the disadvantages described
> in the thread.
> It would need to:
> 1) be completely backwards compatible
> 2) not require additional unpythonic behavior (such as interfaces)
> 3) Existing models should be pluggable with no modification
> 4) Not require any significant change in code base

For the record, I'm not necessarily convinced that (3) is required --
I have no problem with the idea that a feature like plugability should
be opt in -- i.e., an application that wants to have a pluggable User
model needs to actively expose the User model as a point of
configuration. I'm not convinced that completely duck-typed User
replacement (or any other model, for that matter) is desirable,
because it can have all sorts of consequences.

Consider the simple task of bug reporting -- you report a bug with my
application, but I can't reproduce it. It's not until I really dig
into the matter and *then* I discover that you've been swapping out
the User model with a custom model that doesn't meet some requirement
that I may not have even known I was relying on.

It's also worth noting that (4) is desirable, but not absolutely
required. If it's necessary to tear down everything to get a better
implementation, we'll do that -- it's just not the preferred approach
due to the risks involved.

> 4) is the only part I cannot answer fully. I started an implementation, just
> to see if it was even possible,  and I've made some progress - it works with
> quite a few of my test models. However, I am just learning the internals of
> Django, and there are still errors with my implementation. I wanted to put
> this to the list before going further.
> As far as I've gotten with actual implementation: When a project imports the
> original model (original.model), django.db.models.base.ModelBase.__new__
> checks to see if "original.model." is in the COMPONENTS dictionary. If it
> is, it gets the path to the replacement model ("replacement.model2"), and
> gets the replacement class. It calls
> django.db.models.register_models('original', model=) which
> registers the replacement model class under the original application and
> with the name 'model'. Now, there are multiple copies of replacement.model2
> in django.db.models.loading.cache, so django.db.models.get_models() removes
> duplicates before returning all models. There are other internals that will
> need to be modified, besides these three methods, in order to eliminate the
> occasional errors I'm getting in syncdb; I'm still figuring out what those
> are.

Django has been down this path before... and came all the way back.
Our "magic removal" period was the point at which we finally purged
all the import shenanigans from our codebase, and I'm not eager to
revisit those dark times.

In short, messing with imports like this opens up a bag of hurt -- not
the least of which is a series of almost impossible to track down bugs
where the order in which models are imported can affect which model is
*actually* at the end of the rainbow when you say "from
django.contrib.auth.models import User". Even really simple things
like subclassing models can stops working... or worse... work
sometimes, but not always.

So - pluggable models -- yes. Getting pluggable models by messing with
the import/metaclass process -- no thanks.

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.
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: Various small issues

[Russell Keith-Magee]

On Tue, Feb 1, 2011 at 11:45 AM, Brian Neal  wrote:
> On Jan 31, 7:35 pm, Russell Keith-Magee 
> wrote:
>>
>> The core team aren't the only people who can review tickets. In fact,
>> all you need is for someone who isn't you to review your ticket and
>> say that it looks good (by Django's standards -- which means
>> documentation, tests, PEP8 etc). Once you've reviewed a ticket and
>> you're happy, you can promote it to RFC -- which puts it much closer
>> to being committed.
>
> Russ, the advice you gave above doesn't quite jive with what is here:
> http://docs.djangoproject.com/en/dev/internals/contributing/#triage-by-the-general-community
>
> "Please don’t promote tickets to “Ready for checkin” unless they are
> trivial changes – for example, spelling mistakes or broken links in
> documentation."
>
> I held off on marking something RFC because of that. Can you please
> clarify? Thanks.

Darn... i've been hoisted by my own petard... :-)

That particular section of the docs is, to use the technical term,
wrong. :-) It was written back when we had the intention of
maintaining a formal triage team. That idea has proved itself
unworkable, because it doesn't actually remove the bottleneck, it just
makes the neck of the bottle ever so slightly wider.

So, over time, the rules have drifted, until we're at the point we are
now. We've just been slack about updating the documentation of those
rules. There's even a ticket (#14401) that covers the need to do so.
Let's call this one more reminder of things I need to do.

Here's a rough version of what that section needs to say:

Trac is a community-tended garden of issues. Sometimes there are
weeds, sometimes there are flowers and vegetables that need picking.
We need your help to sort out one from the other.

Like all gardens, we can aspire to perfection, but in reality, there's
no such thing. In the most pristine garden there will still be snails
and insects. In a community garden, there will also be helpful people
who, with the best of intentions, fertilize the dandelions and poison
the roses. The job of the community is to self-manage, and try and
keep these problems to a mimimum, and educate those coming into the
community so that they can become valuable contributing members of the
community.

Similarly, while we aim for Trac to be a perfect representation of the
state of progress on Django bugs, we acknowledge that this simply wont
happen. By distributing the load of Trac maintenance to the community,
we accept that there will be inaccuracies and mistakes made. Trac is
"mostly accurate", and we give allowances for the fact that sometimes
it will be wrong.

So how should you interact with Django's Trac install?

Be bold, but err on the side of caution. If you're uncertain if a
ticket is RFC, don't mark is as such. Leave a comment instead, letting
others know your thoughts. If you're mostly certain, but not
completely certain, you might also try asking on IRC to see if someone
else can confirm your suspicions.

Start small. It's easier to get feedback on a little issue than on a big one.

Wait for feedback, and respond to feedback that you receive. Don't
just barge in and mark 50 tickets RFC in a sitting -- especially if
this is your first time. Mark one or two tickets, and wait to see if
the core committers agree. If they commit, then you know your analysis
was correct; if they bounce back to Accepted, they will provide
feedback letting you know what was missing. Address that feedback, and
try again.

Be rigorous. When we say "PEP8, and must have docs and tests", we mean
it. If a patch doesn't have docs and tests, there had better be a good
reason. Arguments like "I couldn't find any existing tests of this
feature" don't carry much weight -- while it may be true, that's an
indication that you should be the person to write the very first tests
for that feature, not that you get a pass from writing tests
altogether.

I hope that clarifies things; I'll try and update the contribution
docs to reflect this sort of sentiment.

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.
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: settings.py should have way to hide key/values even when debug set True

[Matteius]

I was thinking the decorator could apply to whatever setting is
declared directly following it.  If declared, the setting simply
wouldn't show up.  However I could add SECRET or PASSWORD to my token
sensitive settings just as well.

On Jan 31, 7:00 pm, Russell Keith-Magee 
wrote:
> On Tue, Feb 1, 2011 at 12:12 AM, Horst Gutmann  wrote:
> > On Mon, Jan 31, 2011 at 5:02 PM, Matteius  wrote:
> >> I think it would be really useful to have a way (possibly a decorator
> >> such as @hide_setting) such as to protect deployed sites when they
> >> switch over to debug mode.  To me this would be a most useful setting
> >> to have, especially when protecting secret key settings.  Please be
> >> advised.
>
> > If I remember correctly, settings starting with SECRET_ are not shown
> > on the debug page.
>
> Not completely correct. There is a list of settings that won't be
> displayed -- anything that contains the text
> SECRET, PASSWORD, PROFANITIES_LIST,  or SIGNATURE will be replaced
> with asterisks. It's not an unreasonable suggestion that this list
> should be user-configurable.
>
> As for the original proposal - I'm not sure how a decorator would help
> here. What is the decorator being applied to? What would the decorator
> indicate? How would that information be exposed to the debug view?
>
> 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.
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: settings.py should have way to hide key/values even when debug set True

[Alex Gaynor]

On Tue, Feb 1, 2011 at 1:25 AM, Matteius  wrote:

> I was thinking the decorator could apply to whatever setting is
> declared directly following it.  If declared, the setting simply
> wouldn't show up.  However I could add SECRET or PASSWORD to my token
> sensitive settings just as well.
>
> On Jan 31, 7:00 pm, Russell Keith-Magee 
> wrote:
> > On Tue, Feb 1, 2011 at 12:12 AM, Horst Gutmann 
> wrote:
> > > On Mon, Jan 31, 2011 at 5:02 PM, Matteius  wrote:
> > >> I think it would be really useful to have a way (possibly a decorator
> > >> such as @hide_setting) such as to protect deployed sites when they
> > >> switch over to debug mode.  To me this would be a most useful setting
> > >> to have, especially when protecting secret key settings.  Please be
> > >> advised.
> >
> > > If I remember correctly, settings starting with SECRET_ are not shown
> > > on the debug page.
> >
> > Not completely correct. There is a list of settings that won't be
> > displayed -- anything that contains the text
> > SECRET, PASSWORD, PROFANITIES_LIST,  or SIGNATURE will be replaced
> > with asterisks. It's not an unreasonable suggestion that this list
> > should be user-configurable.
> >
> > As for the original proposal - I'm not sure how a decorator would help
> > here. What is the decorator being applied to? What would the decorator
> > indicate? How would that information be exposed to the debug view?
> >
> > 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.
> 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.
>
>
How, precisely, would one apply a decorator to an assignment statement?
 Unless there has been some change to Python's grammar I'm not aware of,
decorators can only be used on function and class definitions.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero

-- 
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: Various small issues

[Klaas van Schelven]

Thanks!

I might add that, for someone who just wants to jump in and do some
random good for the project I found it hard to find pointers to "easy
but necessary (perhaps slightly boring) tasks" on Trac.

Maybe I'm just an edge case :-)

On Feb 1, 6:05 am, Russell Keith-Magee 
wrote:
> On Tue, Feb 1, 2011 at 11:45 AM, Brian Neal  wrote:
> > On Jan 31, 7:35 pm, Russell Keith-Magee 
> > wrote:
>
> >> The core team aren't the only people who can review tickets. In fact,
> >> all you need is for someone who isn't you to review your ticket and
> >> say that it looks good (by Django's standards -- which means
> >> documentation, tests, PEP8 etc). Once you've reviewed a ticket and
> >> you're happy, you can promote it to RFC -- which puts it much closer
> >> to being committed.
>
> > Russ, the advice you gave above doesn't quite jive with what is here:
> >http://docs.djangoproject.com/en/dev/internals/contributing/#triage-b...
>
> > "Please don’t promote tickets to “Ready for checkin” unless they are
> > trivial changes – for example, spelling mistakes or broken links in
> > documentation."
>
> > I held off on marking something RFC because of that. Can you please
> > clarify? Thanks.
>
> Darn... i've been hoisted by my own petard... :-)
>
> That particular section of the docs is, to use the technical term,
> wrong. :-) It was written back when we had the intention of
> maintaining a formal triage team. That idea has proved itself
> unworkable, because it doesn't actually remove the bottleneck, it just
> makes the neck of the bottle ever so slightly wider.
>
> So, over time, the rules have drifted, until we're at the point we are
> now. We've just been slack about updating the documentation of those
> rules. There's even a ticket (#14401) that covers the need to do so.
> Let's call this one more reminder of things I need to do.
>
> Here's a rough version of what that section needs to say:
>
> Trac is a community-tended garden of issues. Sometimes there are
> weeds, sometimes there are flowers and vegetables that need picking.
> We need your help to sort out one from the other.
>
> Like all gardens, we can aspire to perfection, but in reality, there's
> no such thing. In the most pristine garden there will still be snails
> and insects. In a community garden, there will also be helpful people
> who, with the best of intentions, fertilize the dandelions and poison
> the roses. The job of the community is to self-manage, and try and
> keep these problems to a mimimum, and educate those coming into the
> community so that they can become valuable contributing members of the
> community.
>
> Similarly, while we aim for Trac to be a perfect representation of the
> state of progress on Django bugs, we acknowledge that this simply wont
> happen. By distributing the load of Trac maintenance to the community,
> we accept that there will be inaccuracies and mistakes made. Trac is
> "mostly accurate", and we give allowances for the fact that sometimes
> it will be wrong.
>
> So how should you interact with Django's Trac install?
>
> Be bold, but err on the side of caution. If you're uncertain if a
> ticket is RFC, don't mark is as such. Leave a comment instead, letting
> others know your thoughts. If you're mostly certain, but not
> completely certain, you might also try asking on IRC to see if someone
> else can confirm your suspicions.
>
> Start small. It's easier to get feedback on a little issue than on a big one.
>
> Wait for feedback, and respond to feedback that you receive. Don't
> just barge in and mark 50 tickets RFC in a sitting -- especially if
> this is your first time. Mark one or two tickets, and wait to see if
> the core committers agree. If they commit, then you know your analysis
> was correct; if they bounce back to Accepted, they will provide
> feedback letting you know what was missing. Address that feedback, and
> try again.
>
> Be rigorous. When we say "PEP8, and must have docs and tests", we mean
> it. If a patch doesn't have docs and tests, there had better be a good
> reason. Arguments like "I couldn't find any existing tests of this
> feature" don't carry much weight -- while it may be true, that's an
> indication that you should be the person to write the very first tests
> for that feature, not that you get a pass from writing tests
> altogether.
>
> I hope that clarifies things; I'll try and update the contribution
> docs to reflect this sort of sentiment.
>
> 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.
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: Various small issues

[Gabriel Hurley]

As Russ mentioned, check out ticket #14401 [1], and its associated wiki page 
[2]. Those should offer some more insight. That ticket was my pet project to 
start and it's come time to finish it (the vagaries of the real world be 
damned).

If you have particular aspects you'd like to see better explained or that 
would be more useful, please add them to the wiki or leave them as comments 
on the ticket.

All the best,

- Gabriel

[1] http://code.djangoproject.com/ticket/14401
[2] http://code.djangoproject.com/wiki/ContributingHowTo

-- 
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.

Contributing Guide Request For Input

[Gabriel Hurley]

Some time ago I opened ticket 
#14401to address the "how to" 
spirit of contributing to Django as opposed to the 
hard and fast "contributing reference" that we've got currently. I feel the 
time has come for me to wrap up that ticket one way or the other, and I'd 
love to get as much into it as possible before landing it in the docs.

The associated wiki 
pagehas culled quite a 
lot out of the Django Dev discussions, but I'd still love 
to get more collaboration on writing this guide.

I know there are numerous people who feel very strongly on this subject, so 
please, be bold and offer your contribution so that EVERYONE will better 
understand how to work together in contributing!

I'm going to give it about another week before I write it up in reST, so 
now's the time to make your voices heard!

Thanks so much,

- Gabriel Hurley

-- 
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.