Re: Possible Bug in RegexURLResolver

[Marten Kenbeek]

It's not quite as simple. Concurrency is actually not the main issue here. 
The issue is that self._populate() only populates the app_dict, namespace_dict 
and reverse_dict for the currently active language. By short-circuiting if 
the resolver is populating, you have the chance to short-circuit while the 
populating thread has a different active language. The short-circuiting 
thread's language won't have been populated, and that will result in the 
above KeyError.

The issue that self._populating is solving is that a RegexURLResolver can 
recursively include itself if a namespace is used. Namespaces are loaded 
lazily on first access, so this would generally not result in infinite 
recursion. But, to include all namespaced views in self._callback_strs, you 
need to load them immediately. self._populating prevents infinite recursion 
in that specific case.

On a side note: recursively including the same resolver is possible under 
some limited circumstances, but so far I've only seen it happen in the 
Django test suite, and it doesn't even work if you don't include at least 
one namespace between each recursive include. It's an edge-case scenario 
that can be solved better by using a repeating pattern in your regex. I 
don't think that it provides any value, but it does significantly 
complicate the code. Removing this accidental "feature" would solve the 
issue as well, without complicating the code any further. 

Now, to solve the issue within the constraints of the current test suite, 
you only need to prevent that self._populate() is called twice on the same 
object within the same thread. A simple thread-local object should do the 
trick:

class RegexURLResolver(LocaleRegexProvider):
def __init__(self, regex, urlconf_name, default_kwargs=None, 
app_name=None, namespace=None):

...

self._local = threading.local()
self._local.populating = False
...

   def _populate(self):
if self._local.populating:
return
self._local.populating = True
...
self._local.populating = False


This will work concurrently, because all lists (lookups, namespaces, apps) 
are built up in local variables, and then set in 
self._namespace_dict[language_code] etc. as an atomic operation. The worst 
that can happen is that the list is overwritten atomically with an 
identical list. self._callback_strs is a set, so updating it with values 
that are already present is not a problem either.


Marten


On Wednesday, July 13, 2016 at 12:22:36 AM UTC+2, Cristiano Coelho wrote:
>
> Keep in mind your code guys is semantically different from the one of the 
> first post.
>
> In the first post, the _populate method can be called more than once, and 
> if the time window is long enough, the two or more calls will eventually 
> run the # ... populate code again, but on your code, the populate code will 
> only be called once doesn't matter how many times you call _populate, 
> unless the populated variable is restarted somewhere else. So I don't know 
> how is this exactly used but make sure to check it
>
> El martes, 12 de julio de 2016, 14:58:12 (UTC-3), Aymeric Augustin 
> escribió:
>>
>> On 12 Jul 2016, at 19:46, Florian Apolloner  wrote:
>>
>>
>> On Tuesday, July 12, 2016 at 9:25:37 AM UTC+2, Aymeric Augustin wrote:
>>>
>>> Can you check the condition inside the lock? The following pattern seems 
>>> simpler to me:
>>>
>>
>> The standard pattern in such cases is to check inside and outside. 
>> Outside to avoid the lock if you already populated (the majority of 
>> requests) and inside to see if another thread populated it in the time you 
>> waited to get the lock…
>>
>>
>> Yes, actually that’s what I did the last time I implemented this pattern, 
>> in Apps.populate.
>>
>> -- 
>> Aymeric.
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/dfa519d1-cee3-4ed5-b4ff-a5e902b5310e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Possible Bug in RegexURLResolver

[Cristiano Coelho]

If you are using locals it means each thread will always end up calling the 
actual populate code? Is there any point for the RegexURLResolver class to 
be a singleton then?


El jueves, 14 de julio de 2016, 9:12:54 (UTC-3), Marten Kenbeek escribió:
>
> It's not quite as simple. Concurrency is actually not the main issue here. 
> The issue is that self._populate() only populates the app_dict, 
> namespace_dict 
> and reverse_dict for the currently active language. By short-circuiting 
> if the resolver is populating, you have the chance to short-circuit while 
> the populating thread has a different active language. The short-circuiting 
> thread's language won't have been populated, and that will result in the 
> above KeyError.
>
> The issue that self._populating is solving is that a RegexURLResolver can 
> recursively include itself if a namespace is used. Namespaces are loaded 
> lazily on first access, so this would generally not result in infinite 
> recursion. But, to include all namespaced views in self._callback_strs, 
> you need to load them immediately. self._populating prevents infinite 
> recursion in that specific case.
>
> On a side note: recursively including the same resolver is possible under 
> some limited circumstances, but so far I've only seen it happen in the 
> Django test suite, and it doesn't even work if you don't include at least 
> one namespace between each recursive include. It's an edge-case scenario 
> that can be solved better by using a repeating pattern in your regex. I 
> don't think that it provides any value, but it does significantly 
> complicate the code. Removing this accidental "feature" would solve the 
> issue as well, without complicating the code any further. 
>
> Now, to solve the issue within the constraints of the current test suite, 
> you only need to prevent that self._populate() is called twice on the 
> same object within the same thread. A simple thread-local object should do 
> the trick:
>
> class RegexURLResolver(LocaleRegexProvider):
> def __init__(self, regex, urlconf_name, default_kwargs=None, 
> app_name=None, namespace=None):
> 
> ...
>
> self._local = threading.local()
> self._local.populating = False
> ...
>
>def _populate(self):
> if self._local.populating:
> return
> self._local.populating = True
> ...
> self._local.populating = False
>
>
> This will work concurrently, because all lists (lookups, namespaces, apps) 
> are built up in local variables, and then set in 
> self._namespace_dict[language_code] etc. as an atomic operation. The 
> worst that can happen is that the list is overwritten atomically with an 
> identical list. self._callback_strs is a set, so updating it with values 
> that are already present is not a problem either.
>
>
> Marten
>
>
> On Wednesday, July 13, 2016 at 12:22:36 AM UTC+2, Cristiano Coelho wrote:
>>
>> Keep in mind your code guys is semantically different from the one of the 
>> first post.
>>
>> In the first post, the _populate method can be called more than once, and 
>> if the time window is long enough, the two or more calls will eventually 
>> run the # ... populate code again, but on your code, the populate code will 
>> only be called once doesn't matter how many times you call _populate, 
>> unless the populated variable is restarted somewhere else. So I don't know 
>> how is this exactly used but make sure to check it
>>
>> El martes, 12 de julio de 2016, 14:58:12 (UTC-3), Aymeric Augustin 
>> escribió:
>>>
>>> On 12 Jul 2016, at 19:46, Florian Apolloner  wrote:
>>>
>>>
>>> On Tuesday, July 12, 2016 at 9:25:37 AM UTC+2, Aymeric Augustin wrote:

 Can you check the condition inside the lock? The following pattern 
 seems simpler to me:

>>>
>>> The standard pattern in such cases is to check inside and outside. 
>>> Outside to avoid the lock if you already populated (the majority of 
>>> requests) and inside to see if another thread populated it in the time you 
>>> waited to get the lock…
>>>
>>>
>>> Yes, actually that’s what I did the last time I implemented this 
>>> pattern, in Apps.populate.
>>>
>>> -- 
>>> Aymeric.
>>>
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a9788779-8a04-44f1-b18b-e8048f4c6a4f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: status of 1.10 release blockers

[Tim Graham]

I'm planning for the release candidate on Monday.

The one blocker is #26888  - 
RegexURLResolver doesn't work in threaded environments.

On Tuesday, June 21, 2016 at 4:29:47 PM UTC-4, Tim Graham wrote:
>
> The blocker is merged so I'll release the beta in a couple hours if no one 
> stops me.
>
> On Monday, June 20, 2016 at 9:10:12 PM UTC-4, Tim Graham wrote:
>>
>> The remaining blocker:
>>
>> UserCreationForm doesn't call normalize_email and normalize_username
>> https://code.djangoproject.com/ticket/26719
>> Status: I sent some final edits to the PR and it should be ready for 
>> commit tomorrow.
>>
>> Other possible blockers:
>>
>> Different manager for _base_manager and related descriptors
>> https://code.djangoproject.com/ticket/26749
>> django-hvad is broken by the manager inheritance refactor and it's 
>> unclear if it can be adapted for the new behavior.
>>
>> Update decorator_from_middleware() to work with DEP5 style middleware.
>> https://code.djangoproject.com/ticket/26626
>> Design decision needed, see 
>> https://groups.google.com/d/topic/django-developers/hNQIaYcN3xM/discussion
>>
>> As long as no new issues pop up by tomorrow, I'm thinking to do the beta 
>> release then. We might consider a "beta 2" release around 2 weeks later if 
>> we decide to push fixes for the other two issues.
>>
>> On Saturday, June 18, 2016 at 8:05:32 PM UTC-4, Tim Graham wrote:
>>>
>>> I'm postponing the release until next week as some release blockers 
>>> remain:
>>>
>>>
>>> https://code.djangoproject.com/query?status=!closed&severity=Release%20blocker
>>>
>>> On Friday, June 17, 2016 at 5:33:04 PM UTC-4, Claude Paroz wrote:

 Le vendredi 17 juin 2016 16:52:50 UTC+2, Tim Graham a écrit :
>
> There are a few small issues to finish up, but if all goes well, the 
> beta release will happen sometime tomorrow (at least 24 hours from now).
>

 I'm a bit worried about https://code.djangoproject.com/ticket/26719 
 which could have security implications for 1.10. To be investigated...

 Claude

>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/94dd42e9-6940-4377-bd8e-7b285d0a63bc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Possible Bug in RegexURLResolver

[Marten Kenbeek]

Using a singleton means that everything is cached for the lifetime of the 
process after the resolver has been populated. The thread-local is so that 
concurrent calls to _populate() can correctly determine if it is a 
recursive call within the current thread. _populate() is called *at most* 
once per thread for each language. If one thread finishes populating before 
another thread starts, that second thread can access the thread-independent 
cache and won't have to populate the resolver again.

On Thursday, July 14, 2016 at 3:15:43 PM UTC+2, Cristiano Coelho wrote:
>
> If you are using locals it means each thread will always end up calling 
> the actual populate code? Is there any point for the RegexURLResolver class 
> to be a singleton then?
>
>
> El jueves, 14 de julio de 2016, 9:12:54 (UTC-3), Marten Kenbeek escribió:
>>
>> It's not quite as simple. Concurrency is actually not the main issue 
>> here. The issue is that self._populate() only populates the app_dict, 
>> namespace_dict 
>> and reverse_dict for the currently active language. By short-circuiting 
>> if the resolver is populating, you have the chance to short-circuit while 
>> the populating thread has a different active language. The short-circuiting 
>> thread's language won't have been populated, and that will result in the 
>> above KeyError.
>>
>> The issue that self._populating is solving is that a RegexURLResolver can 
>> recursively include itself if a namespace is used. Namespaces are loaded 
>> lazily on first access, so this would generally not result in infinite 
>> recursion. But, to include all namespaced views in self._callback_strs, 
>> you need to load them immediately. self._populating prevents infinite 
>> recursion in that specific case.
>>
>> On a side note: recursively including the same resolver is possible under 
>> some limited circumstances, but so far I've only seen it happen in the 
>> Django test suite, and it doesn't even work if you don't include at least 
>> one namespace between each recursive include. It's an edge-case scenario 
>> that can be solved better by using a repeating pattern in your regex. I 
>> don't think that it provides any value, but it does significantly 
>> complicate the code. Removing this accidental "feature" would solve the 
>> issue as well, without complicating the code any further. 
>>
>> Now, to solve the issue within the constraints of the current test suite, 
>> you only need to prevent that self._populate() is called twice on the 
>> same object within the same thread. A simple thread-local object should do 
>> the trick:
>>
>> class RegexURLResolver(LocaleRegexProvider):
>> def __init__(self, regex, urlconf_name, default_kwargs=None, 
>> app_name=None, namespace=None):
>> 
>> ...
>>
>> self._local = threading.local()
>> self._local.populating = False
>> ...
>>
>>def _populate(self):
>> if self._local.populating:
>> return
>> self._local.populating = True
>> ...
>> self._local.populating = False
>>
>>
>> This will work concurrently, because all lists (lookups, namespaces, apps) 
>> are built up in local variables, and then set in 
>> self._namespace_dict[language_code] etc. as an atomic operation. The 
>> worst that can happen is that the list is overwritten atomically with an 
>> identical list. self._callback_strs is a set, so updating it with values 
>> that are already present is not a problem either.
>>
>>
>> Marten
>>
>>
>> On Wednesday, July 13, 2016 at 12:22:36 AM UTC+2, Cristiano Coelho wrote:
>>>
>>> Keep in mind your code guys is semantically different from the one of 
>>> the first post.
>>>
>>> In the first post, the _populate method can be called more than once, 
>>> and if the time window is long enough, the two or more calls will 
>>> eventually run the # ... populate code again, but on your code, the 
>>> populate code will only be called once doesn't matter how many times you 
>>> call _populate, unless the populated variable is restarted somewhere else. 
>>> So I don't know how is this exactly used but make sure to check it
>>>
>>> El martes, 12 de julio de 2016, 14:58:12 (UTC-3), Aymeric Augustin 
>>> escribió:

 On 12 Jul 2016, at 19:46, Florian Apolloner  wrote:


 On Tuesday, July 12, 2016 at 9:25:37 AM UTC+2, Aymeric Augustin wrote:
>
> Can you check the condition inside the lock? The following pattern 
> seems simpler to me:
>

 The standard pattern in such cases is to check inside and outside. 
 Outside to avoid the lock if you already populated (the majority of 
 requests) and inside to see if another thread populated it in the time you 
 waited to get the lock…


 Yes, actually that’s what I did the last time I implemented this 
 pattern, in Apps.populate.

 -- 
 Aymeric.




-- 
You received this message because you are subscribed to the Google Groups 
"Dja

Re: Possible Bug in RegexURLResolver

[Markus Holtermann]

Thanks everybody!

While Aymeric's sounded great, your reasoning sounds even better,
Marten. Thanks!

Do you want to provide a PR for that, Marten?

Cheers,

/Markus

On Thu, Jul 14, 2016 at 06:47:15AM -0700, Marten Kenbeek wrote:

Using a singleton means that everything is cached for the lifetime of the
process after the resolver has been populated. The thread-local is so that
concurrent calls to _populate() can correctly determine if it is a
recursive call within the current thread. _populate() is called *at most*
once per thread for each language. If one thread finishes populating before
another thread starts, that second thread can access the thread-independent
cache and won't have to populate the resolver again.

On Thursday, July 14, 2016 at 3:15:43 PM UTC+2, Cristiano Coelho wrote:


If you are using locals it means each thread will always end up calling
the actual populate code? Is there any point for the RegexURLResolver class
to be a singleton then?


El jueves, 14 de julio de 2016, 9:12:54 (UTC-3), Marten Kenbeek escribió:


It's not quite as simple. Concurrency is actually not the main issue
here. The issue is that self._populate() only populates the app_dict, 
namespace_dict
and reverse_dict for the currently active language. By short-circuiting
if the resolver is populating, you have the chance to short-circuit while
the populating thread has a different active language. The short-circuiting
thread's language won't have been populated, and that will result in the
above KeyError.

The issue that self._populating is solving is that a RegexURLResolver can
recursively include itself if a namespace is used. Namespaces are loaded
lazily on first access, so this would generally not result in infinite
recursion. But, to include all namespaced views in self._callback_strs,
you need to load them immediately. self._populating prevents infinite
recursion in that specific case.

On a side note: recursively including the same resolver is possible under
some limited circumstances, but so far I've only seen it happen in the
Django test suite, and it doesn't even work if you don't include at least
one namespace between each recursive include. It's an edge-case scenario
that can be solved better by using a repeating pattern in your regex. I
don't think that it provides any value, but it does significantly
complicate the code. Removing this accidental "feature" would solve the
issue as well, without complicating the code any further.

Now, to solve the issue within the constraints of the current test suite,
you only need to prevent that self._populate() is called twice on the
same object within the same thread. A simple thread-local object should do
the trick:

class RegexURLResolver(LocaleRegexProvider):
def __init__(self, regex, urlconf_name, default_kwargs=None,
app_name=None, namespace=None):

...

self._local = threading.local()
self._local.populating = False
...

   def _populate(self):
if self._local.populating:
return
self._local.populating = True
...
self._local.populating = False


This will work concurrently, because all lists (lookups, namespaces, apps)
are built up in local variables, and then set in
self._namespace_dict[language_code] etc. as an atomic operation. The
worst that can happen is that the list is overwritten atomically with an
identical list. self._callback_strs is a set, so updating it with values
that are already present is not a problem either.


Marten


On Wednesday, July 13, 2016 at 12:22:36 AM UTC+2, Cristiano Coelho wrote:


Keep in mind your code guys is semantically different from the one of
the first post.

In the first post, the _populate method can be called more than once,
and if the time window is long enough, the two or more calls will
eventually run the # ... populate code again, but on your code, the
populate code will only be called once doesn't matter how many times you
call _populate, unless the populated variable is restarted somewhere else.
So I don't know how is this exactly used but make sure to check it

El martes, 12 de julio de 2016, 14:58:12 (UTC-3), Aymeric Augustin
escribió:


On 12 Jul 2016, at 19:46, Florian Apolloner  wrote:


On Tuesday, July 12, 2016 at 9:25:37 AM UTC+2, Aymeric Augustin wrote:


Can you check the condition inside the lock? The following pattern
seems simpler to me:



The standard pattern in such cases is to check inside and outside.
Outside to avoid the lock if you already populated (the majority of
requests) and inside to see if another thread populated it in the time you
waited to get the lock…


Yes, actually that’s what I did the last time I implemented this
pattern, in Apps.populate.

--
Aymeric.





--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr.

Re: status of 1.10 release blockers

[Markus Holtermann]

Thank you for the update, Tim.

#26888 will be taken care of by tomorrow. Either Marten or I are pushing
a PR.

Cheers,

/Markus

On Thu, Jul 14, 2016 at 06:41:51AM -0700, Tim Graham wrote:

I'm planning for the release candidate on Monday.

The one blocker is #26888  -
RegexURLResolver doesn't work in threaded environments.

On Tuesday, June 21, 2016 at 4:29:47 PM UTC-4, Tim Graham wrote:


The blocker is merged so I'll release the beta in a couple hours if no one
stops me.

On Monday, June 20, 2016 at 9:10:12 PM UTC-4, Tim Graham wrote:


The remaining blocker:

UserCreationForm doesn't call normalize_email and normalize_username
https://code.djangoproject.com/ticket/26719
Status: I sent some final edits to the PR and it should be ready for
commit tomorrow.

Other possible blockers:

Different manager for _base_manager and related descriptors
https://code.djangoproject.com/ticket/26749
django-hvad is broken by the manager inheritance refactor and it's
unclear if it can be adapted for the new behavior.

Update decorator_from_middleware() to work with DEP5 style middleware.
https://code.djangoproject.com/ticket/26626
Design decision needed, see
https://groups.google.com/d/topic/django-developers/hNQIaYcN3xM/discussion

As long as no new issues pop up by tomorrow, I'm thinking to do the beta
release then. We might consider a "beta 2" release around 2 weeks later if
we decide to push fixes for the other two issues.

On Saturday, June 18, 2016 at 8:05:32 PM UTC-4, Tim Graham wrote:


I'm postponing the release until next week as some release blockers
remain:


https://code.djangoproject.com/query?status=!closed&severity=Release%20blocker

On Friday, June 17, 2016 at 5:33:04 PM UTC-4, Claude Paroz wrote:


Le vendredi 17 juin 2016 16:52:50 UTC+2, Tim Graham a écrit :


There are a few small issues to finish up, but if all goes well, the
beta release will happen sometime tomorrow (at least 24 hours from now).



I'm a bit worried about https://code.djangoproject.com/ticket/26719
which could have security implications for 1.10. To be investigated...

Claude





--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/94dd42e9-6940-4377-bd8e-7b285d0a63bc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20160714140527.GC5382%40inel.local.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: structural & functional review of django documentation

[Doug Epling]

On Friday, January 1, 2016 at 11:48:24 PM UTC-5, Doug Epling wrote:
>
> Hey Tim --
>
> Basically, we need data.  My recommendation involves two separate 
> initiatives.  
>
> First is, has been, a discussion open for spectators but limited 
> participants to core members.  Asside from its subject pertaining current 
> state and future path, all other details are above my pay grade.
>

Actually, whatever on that first point.

But on this second point it entirely not necessary.  Django has all the 
feedback in textual form that it would ever need for some user analysis.  I 
did not realize the extent of the IRC logs.  This body of text is a 
treasure chest.  And Django should be mining it for all it is worth.
 

> Second is, has been, the active solicitation of a standardized body of 
> feedback from the peripheral users of Django documentation in a fairly 
> substantial amount.  We might want to start a new discussion thread on this 
> particular topic.
>
> Many thanks for your hard work and dedication. 
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/facc1359-7ec6-4683-b5f4-eeeabbc29e20%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

User representation on Django admin object history page.

[Matheus Bratfisch]

Hello,

I have been trying to update the user text on history of an object page.
Looking into django source code I saw get_username being called directly.
So overriding the __str__ method on User model will not update the User
value on History page.

Right now the __str__ method of an user is:

def __str__(self):

return self.get_username()
>

Can we update the object_history.html template to use __str__
representation instead of calling get_username method? It seems more
correct. What do you guys think?  Or is there a reason to call get_username
directly?



Best regards,
--
Matheus (X-warrior) Bratfisch.
http://matbra.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAED0SFyUR09LpJb07FjL6o%3DqqVLMjSZ10-2_dtqabDxw8rbX4g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Official Projects DEP

[Andrew Godwin]

I am happy to report that the Official Projects DEP, number 0007, was
approved by the Technical Board and is now adopted as final!

Andrwe
On 4 Jul 2016 11:39 am, "Andrew Godwin"  wrote:

> I've revised the documentation section for clarity about external hosting,
> and given the lack of further discussion or dissention, I'm now taking the
> DEP to the technical board for a decision.
>
> Andrew
>
> On Sun, Jun 12, 2016 at 4:35 AM, Andrew Godwin 
> wrote:
>
>>
>> On 12 Jun 2016 2:00 a.m., "Tim Graham"  wrote:
>>
>> >
>> > 1. It might be nice if projects had more than one shepherd so there's
>> not a single point of failure. Of course, if all members of the maintenance
>> team end up joining the team, then there's no issue.
>>
>> It depends how the role of work is split between them; I think it depends
>> on the project too. I'd rather not over legislate here and let us have some
>> leeway based on context. I agree we should aim for this if the shepherd
>> role is very busy for that project, but with a maintenance team we
>> hopefully have a ready source of knowledgeable potential new core team
>> members.
>>
>> >
>> >
>> > 2. Re: "The main project documentation does not have to be hosted
>> inside the main Django documentation, but should be under an official
>> Django domain if possible, and link back to with the main Django
>> documentation where it makes sense."
>> >
>> >
>> > I'd rather not get into hosting more documentation on djangoproject.org
>> if possible, as there's a non-trivial maintenance burden there. I imagine
>> it would be easier for the project's maintenance team to make adjustments
>> in the readthedocs UI instead of bothering the Django ops team in the event
>> of any problems.
>>
>> This is why I said domain, not infrastructure; I'd like us to host on RTD
>> with a custom django project subdomain so we retain control of the URLs in
>> the long term but we can pay them to host and deal with it all in the short
>> term.
>>
>> >
>> >
>> > 3. Did you envision any involvement from the Django Fellow in these
>> projects? To date, I haven't really had much involvement with any of the
>> ancillary projects like localflavor and formtools.
>>
>> I didn't, mostly as I didn't want to add more responsibilities to the
>> existing set; do you think we should? I think asking the project to come
>> with a plan for that stuff is helpful, and if it would need Fellow
>> involvement, the proposal should include them as part of the maintenance
>> team maybe?
>>
>> Andrew
>>
>> >
>> >
>> > On Friday, June 10, 2016 at 3:01:23 AM UTC-4, Andrew Godwin wrote:
>> >>
>> >> Just to update on this, there was some good feedback on the draft for
>> writing and clarity, and it's now made it into an official draft, located
>> here:
>> https://github.com/django/deps/blob/master/draft/0007-official-projects.rst
>> >>
>> >> If you'd like to read through the draft and raise discussion points or
>> opinions on the plan, now is the time!
>> >>
>> >> Andrew
>> >>
>> >> On Wed, Jun 8, 2016 at 1:34 PM, Andrew Godwin 
>> wrote:
>> >>>
>> >>> Hi everyone,
>> >>>
>> >>> I've started on an "official projects" process DEP as I discussed
>> here a while back, to formalise the process of adopting non-core packages
>> as repositories under the official Django organisation, with a view to
>> taking Channels on this route (and hopefully including the existing
>> localflavor under this too).
>> >>>
>> >>> Pull request is up here: https://github.com/django/deps/pull/23 -
>> comments welcome.
>> >>>
>> >>> Andrew
>> >>
>> >>
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups "Django developers (Contributions to Django itself)" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an email to django-developers+unsubscr...@googlegroups.com.
>> > To post to this group, send email to django-developers@googlegroups.com
>> .
>> > Visit this group at https://groups.google.com/group/django-developers.
>> > To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/2d85ebf4-2699-4faf-bb3a-d9c213b76fe2%40googlegroups.com
>> .
>> > For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFwN1urt9FGmACnh%3DVHJ1J927gwHk-PbJY%2BAw1XBDBwaE8oX6A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.